It’s surprising how many organizations collect social security numbers during the resume submission / job application process. I’ve found cases in both the public and private sectors:
Public Sector example:
Private Sector example #1: (note that the privacy policy for this site specifically said that they don't collect social security numbers over the web!!)
Private sector example #2: (hosted by a 3rd party)
In the case of the public sector, one of the recommendations that came out of the April 2007 President’s Identity Task Force Strategic Plan was on page 5:
"Decrease the Unnecessary Use of Social Security Numbers in the Public Sector by Developing Alternative Strategies for Identity Management
• Survey current use of SSNs by federal government
• Issue guidance on appropriate use of SSNs
• Establish clearinghouse for “best” agency practices that minimize use of SSNs
• Work with state and local governments to review use of SSNs"
It looks like the public sector has a lot more work on its hands in order to comply with the Task Force’s recommendations.
I suspect that the cases in the private sector are because of some old legacy collection methods (this is just a guess, I haven’t contacted these organizations) however when you consider the recent increase in web application attacks, all organizations should be looking at all applications that collect sensitive information over the web.
All of these organizations could benefit by using a process like Microsoft’s Security Development Lifecycle during software development or product acquisition. The SDL process has 14 stages across 7 phases (Training, Requirements, Design, Implementation, Verification, Release, Response). What follows is a brief summary of how an organization might use the SDL process to develop an application that collects applicant information over the web.
The Training Phase contains Stage 0: Security and Privacy Education and Awareness. There are many very good points that are made in the SDL book, here’s a summary of a couple:
If your company creates or uses software that stores or maintains sensitive or confidential data, your engineers must understand the basics of privacy.
All developers, testers, and program managers must complete one security training class each year.
The second point is critical. Attacks get better over time. Michael Howard provides a good example of this. In March of 2004, a white paper was published by Sanctum regarding HTTP Response Splitting, by August of 2004, Microsoft had to issue MS04-026 because it found OWA had this vulnerability. This is a perfect example of a threat that could never have been discovered before product release because no one knew it was a threat!
In the overall cost of software development, the cost of education (in terms of time and effort) is tiny; however, the risk of security errors being introduced without proper education is high.
The Requirements Phase contains Stage 1: Project Inception and Stage 2: Cost Analysis. Here is where you determine if the project should go through the SDL process, and if so, perform a security risk assessment to identify potential security risks and come up with a privacy impact rating. The Privacy impact ratings are P1 – High risk, P2 – Moderate risk, P3 Low risk.
The E-Government Act of 2002 requires all Federal government agencies to conduct a Privacy Impact Assessment (PIA) for all new or substantially changed technology that collects, maintains, or disseminates personally identifiable information. For organizations that aren’t required to create a PIA, the Sample SDL Privacy Questionnaire is a good starting point, and gives examples of P1-P3 ratings.
In our HR example, P1 would be triggered because it meets the following definition: “The feature, product, or service stores or transfers Personally Identifiable Information….” The outcome of receiving a P1 Privacy Impact classification is the requirement to review the guidance in the “Understand Your Obligations and Try to Lower Your Risk” section of the SDL Privacy Questionnaire. At this stage you probably would have attempted to estimate what percentage of individuals are asked to interview after submitting an on-line application and resume, and determine if the risk of collecting this information was really worth it. Higher risk translates to higher development and support cost.
This rating would also trigger the creation of a draft Privacy Disclosure, which would eliminate a situation where the Web Privacy Policy conflicted with what was really being collected.
The Design Phase contains Stage 3: Design Best Practices, and Stage 4: Risk Analysis. Here is where defining the security architecture and design guidelines and coding best practices like no SQL statements should be created using string concatenation, prepared statements should be used, and deny access to underlying tables and objects. Only grant access through stored procedures, and use libraries like AntiXSS. The Risk Analysis stage of this phase includes Threat Modeling and a review of the project with a Privacy expert if a high risk ranking of P1 has been assigned.
The Implementation Phase contains Stage 5: Creating Documentation and Tools for Users that Address Security and Privacy, and Stage 6: Establish and Follow Best Practices for Development. Here the coding, testing and integration occur. This is where secure build and code analysis tools are used such as Microsoft Source Code Analyzer for SQL Injection (MSCASI) , and the Cross Site Scripting tool, XSSDetect, FxCop, and others.
The Verification Phase contains Stage 7: Security and Privacy Testing, and Stage 8: Security Push. The software is functionally complete, and beta testing begins. Here is where you make sure that Security features and functionality cannot be circumvented, and threat models are updated as necessary. Finding bugs is the priority.
The Release Phase contains Stage 9: Pre-Release Phase: Public Release Privacy Review, Stage 10: Release Phase: Response Planning, Stage 11: Release Phase: Final Security Review and Privacy Review, and Stage 12: Release Phase: RTM/RTW. For our HR project, this is where all of the change management approvals occur to move the software into production.
The Response Phase contains Stage 13: Response Execution. This is where plans are put in place for what happens if something goes wrong, and what happens if there is vulnerability. Take a look at the sample SDL Privacy Escalation Response Framework document.
If your organization is using development processes based on Agile, you will find that the SDL will also fit into that environment. Details can be found in Chapter 18 of the SDL book.
A summary of where to find these stages in the SDL book can be found in the Sample Security Plan. By using a process like the SDL, you probably would have determined that you really didn’t need to collect that social security number, and saved your organization a lot of money during development, and eliminated potential breaches.
Posts
