<![CDATA[[SecurityRatty] tag: scrub]]> http://securityratty.com/tag/scrub Wed, 09 Apr 2008 15:13:00 +0000 iRatty Engine http://blogs.law.harvard.edu/tech/rss <![CDATA[NetBarrier X5]]> http://securityratty.com/article/2b26807d12ce51084d97c0ba35b36100 http://securityratty.com/article/2b26807d12ce51084d97c0ba35b36100 Tue, 02 Sep 2008 20:00:00 +0000 netbarrier netbarrier firewall block trojan horses firewall tools security suite offers tools scrub personal data block cookies users NetBarrier X5 <![CDATA[Excel Spreadsheet on the web exposes Army officers and civilians]]> http://securityratty.com/article/3579588fd6b1623770eef27c0456e961 http://securityratty.com/article/3579588fd6b1623770eef27c0456e961 Security Breach

Date Reported:
4/4/08

Organization:
United States Army

Contractor/Consultant/Branch:
United States Army Acquisition Support Center ("USAASC")

Victims:
"Colonels and civilians who managed programs within ASC"

Number Affected:
"about two dozen"

Types of Data:
"name, rank, program and organization" and Social Security numbers

Breach Description:
"A spreadsheet containing a "hidden" column of Social Security numbers belonging to about two dozen officers and civilian employees of one Army agency was left on the agency's website for five months after being notified of the presence of the personal information."

Reference URL:
Federal News Radio
USAASC response

Report Credit:
Patience Wait, Federal News Radio

Response:
From the online sources cited above:

A spreadsheet containing a "hidden" column of Social Security numbers belonging to about two dozen officers and civilian employees of one Army agency was left on the agency's website for five months after being notified of the presence of the personal information.
[Evan] Let's get this straight.  The USAASC was notified about it five months ago and nothing was done about it?  How do you explain that?

The Army's Acquisition Support Center has temporarily shut down its website to scrub the information from the spreadsheet   

"We regret that this error occurred. We have temporarily taken the web site down to make the necessary corrections. We will bring the website back online once the corrections have been verified," an Army spokesman responded in an email.

"We are also in the process of informing the individuals on the spreadsheet that their information was made available to the public."

The spokesman's email stated that the agency was investigating why the information had been included on the spreadsheet to begin with, and why it was still on the website five months after ASC was notified of its presence.

A computer expert who works for a federal contractor was surfing the web while doing research and found the spreadsheet in November.

The file contained a list of Colonels and civilians who managed programs within ASC. Visible columns listed their name, rank, program and organization.

In Microsoft Excel, however, every column is labeled with a letter of the alphabet, and the columns in this spreadsheet read, "A-B-D-E," indicating that column C was hidden. A simple command, "unhide," revealed the column of Social Security numbers.

FederalNewsRadio has obtained a copy of the email sent by the expert to ASC warning of the presence of the SSNs. The agency responded to the expert that the matter was being turned over to its executive officer for "review and correction."
[Evan] This is interesting.

But the information was still present on ASC's Web site on April 3, five months to the day after ASC promised it would be corrected.

FederalNewsRadio contacted one person on the list, to confirm the number shown next to his name was in fact his Social Security number.

The man declined to directly confirm the number, but he was clearly shocked, and asked several questions, including requesting the link so he could see it for himself.

While only a handful of people were affected by the lapse, it is a violation of federal policy.

"It is a big issue," says Ari Schwartz, vice president of the Center for Democracy and Technology. "It would seem to be a violation of the [Office of Management and Budget] memo that just went out that said agencies should be cutting down on the use of Social Security numbers, as well as the Privacy Act."

Cate and Schwartz both agreed that PII leaked over the Internet is much more dangerous than widely publicized incidents involving lost and stolen laptops containing similar information, because once on the web, data lives forever.

In response to an article written by FederalNewsRadio.com on Friday, April 4, 2008, regarding an error made by the United States Army Acquisition Support Center (USAASC) in a posting to its Web site, we would like to reassure those whose personal information may have been inadvertently listed that we have taken action to both remove the information from USAASC’s Web site and verify that no other personal information remains available on the Web site.

USAASC and its staff members serving our country around the world, sincerely regret the error made and the additional delay incurred in taking corrective action.

In accordance with federal directives, as well as a matter of policy and practice, USAASC works diligently to safeguard both sensitive data and personal information.

At USAASC, we are confident that we have appropriately addressed this issue and instituted new policies so that such an oversight will not occur in the future.

Again, we regard people’s personal information as extremely private and worthy of the highest level of protection and we greatly appreciate the understanding of those involved.

Commentary:
The apology and responses by the USAASC sound sincere, but how do they explain the complete lack of attention to the original notification in November?  The USAASC only responded once they were notified by the press.

Past Breaches:
Unknown

]]> Sun, 13 Apr 2008 16:23:28 +0000 web personal information remains personal information army usaascs web site information spreadsheet usaasc response usaasc Excel Spreadsheet on the web exposes Army officers and civilians <![CDATA[Microsoft SDL Process in detail]]> http://securityratty.com/article/24d4e4718f449664310a9dbbe27444a0 http://securityratty.com/article/24d4e4718f449664310a9dbbe27444a0

Hello all – Dave here…

I am currently at RSA and decided to take a few moments to blog about some updates to the Security Development Lifecycle.  Admittedly, I have been “radio silent” on the blog for awhile – for those that know me, that’s usually a warning signal that I am cooking something up…

Anyway, back when we first started this blog we promised that you would see more about the particulars of the SDL – and I think we have done a reasonably good job.  Michael Howard has written some pretty interesting pieces on a wide variety of subjects; bug post-mortems, philosophical notes and the like.  Adam Shostack did a fabulous job on the threat modeling series; Eric Bidstrup took a deeper look at the perceived vs. real benefits of the Common Criteria and I have penned a moderately well received screed or two from time to time.

However, one of the common requests (complaints?) that I have heard is that we have been short on the real “guts” of the SDL – that is to say, a point by point examination of how to apply the SDL. I would argue that Michael and Steve’s book on the SDL is a good primer on how to get started.  I think Jeremy Dallman added more momentum with his “Crawling toward SDL” post, giving some practical advice on how to approach the issue of secure software development from scratch.

Despite these efforts I have heard that people still want more detail – some folks are curious about how an organization the size of Microsoft programmatically drives culture change; others are looking for guidance that can be repurposed for their own organizations and finally, some folks are convinced that we are deliberately holding back some security “secret sauce” for some reason.  Go figure.

With that, let me cut to the chase.  Today, we have made the Microsoft Security Development Lifecycle, version 3.2 available for your perusal on MSDN.  This has been in the works for quite awhile and has involved a ton of folks in SEC and TWC putting in a lot of hours and resources into getting this published (props to Ziv Fass and Jed Pickel!).


As you can probably guess, this is not an exact duplication of the SDL for a number of reasons – but it’s pretty darn close. Given that caveat, allow me to illustrate a few points about this guidance...

 

  • First, we have gone through and removed Microsoft specific jargon, references to internal resources on our intranet, and things that would likely make zero sense to an audience outside of Microsoft (the scrub work was one of the primary inhibitors to publishing previous versions of the guidance).
  • Second, this is a generalized representation of how the SDL is applied at Microsoft for the development of rich client and server applications – while many of the principles apply to the creation of web applications, I would caution you to view this in the correct context.  While Bryan Sullivan has written about web development in the past we’ll have more on SDL and web application development in the future.
  • Third, for all intents and purposes the SDL is considered the “minimum bar” for security and privacy at Microsoft for those products with meaningful security risk; there are a number of teams that choose to invest more time and resources as necessary to meet product team goals that may exceed the SDL.  We salute that behavior.  : )

Finally, in reference to the third point above, I am compelled to say the following. (LEGAL DISCLAIMER ALERT – those with weak constitutions should avert their eyes):

 

The following documentation on the Microsoft Security Development Lifecycle, version 3.2 is for illustrative purposes only. This documentation is not an exhaustive reference on the SDL process as practiced at Microsoft. Additional assurance work may be performed by product teams (but not necessarily documented) at their discretion. As a result, this example should not be considered as the exact process that Microsoft follows to secure all products.

This documentation should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented herein. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, OR STATEMENTS ABOUT APPLICABILITY OR FITNESS OF PURPOSE FOR ANY ORGANIZATION ABOUT THE INFORMATION IN THIS DOCUMENT.

 

For the morbidly curious: Yes, I wrote that; yes, it passes legal muster; no, I am not a lawyer, nor do I play one on TV.  : )

So there you have it – Microsoft SDL 3.2.

There are a few sharp eyed souls that read the blog and will wonder about our publishing schedule for updates – it’s no secret that we examine the SDL every six months and either add new requirements to meet emerging threats or deprecate old guidance.  It has been described by some as analogous to “changing tires on a moving vehicle.”  Let me say now that we will NOT be publishing new SDL guidance on a six month schedule for the foreseeable future – we’ll settle on a reasonable publication frequency and hopefully accelerate over time.


I welcome your thoughts and comments...

 

]]> Wed, 09 Apr 2008 15:13:00 +0000 sdl microsoft sdl sdl process microsoft sdl guidance guidance secure secure software development development Microsoft SDL Process in detail