Spammer campaign exploits email read receipts

In the past month we have seen a new wave of malicious spam which relies on requests for delivery confirmations of unsolicited emails. http://www.scmagazineus.com/Spammer-campaign-exploits-email-read-receipts/article/119130/ This spam has 3 traps in it.

First, if you read the message and allow images to be displayed, the retrieval of the image will cause your email address to be placed in the spammers list of valid addresses.

Second, if you delete the email message, and don't have "ask me before sending a response" or "never send a response" turned on in your email tracking options tools menu, an email return receipt confirmation will be automatically sent to the spammer when you delete the message, verifying the validity of your email address.

Third, if you choose the unsubscribe or opt-out option contained within the email message, you will again cause your email address to be placed in the spammers list of valid addresses.

This highlights how important it is to disable the email preview option of your email application, especially if you don't block images from being loaded. Additionally, check how your email application handles read receipts/confirmations, you may be telling spammers that they have a valid email address simply by deleting the message, which will invite even more spam.

Certified Secure Software Lifecycle Professional

The (ISC)² launched a brand new certification program, the Certified Secure Software Lifecycle Professional (CSSLP) www.isc2.org/csslp. The CSSLP is designed to validate secure software development practices and expertise and address the increasing number of application vulnerabilities.

Code-language neutral, it will be applicable to anyone involved in the Systems Development Life Cycle (SDLC), including analysts, developers, software engineers, software architects, project managers, software quality assurance testers and programmers.

The following domains make up the CSSLP Common Body of Knowledge:

Secure Software Concepts - security implications in software development

Secure Software Requirements - capturing security requirements in the requirements gathering phase

Secure Software Design - translating security requirements into application design elements

Secure Software Implementation / Coding - testing for security functionality and resiliency to attack, and developing secure code and exploit mitigation

Secure Software Testing - testing for security functionality and resiliency to attack

Software Acceptance - security implication in the software acceptance phase

Software Deployment, Operations, Maintenance and Disposal - security issues around steady state operations and management of software

The CSSLP certification program joins a number of other existing certification programs:

IEEE:

Certified Software Development Associate (CSDA) and Certified Software Development Professional (CSDP) http://www.computer.org/certification

SANS:

GIAC Secure Software Programmer (GSSP) Certification (Language specific/secure coding, presently Java and C) http://www.sans.org/gssp/

ISSECO:

International Secure Software Engineering Council CSSE Certified Professional for Secure Software Engineering http://www.isseco.org/

When certified professionals are part of an SDLC program that incorporates secure processes and policies, significant progress is made in achieving software assurance.

How Risky is your HR job application process?

How well does your organization manage risk within the domain of information security? The answer to that question probably depends on how well your organization knows where sensitive Personally Identifiable Information (PII) is collected and stored. There is one place that you should make sure you don’t overlook as you inventory your data – your HR job application process.

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.

Getting Started - put Security into your SDLC

The most important thing you can do to integrate Security into your SDLC process is to get started. It doesn't matter if you pick Microsoft's SDL, CERT's SQUARE process, Gary McGraw's Touchpoints, or NIST's SP800-64 just get started!

Jeremy Dallman has put together a series of posts using the analogy of "crawl, walk and run" in the SDL blog as a way of providing some basic starting points that would move your organization toward implementing a version of Microsoft’s Security Development Lifecycle (SDL). He has completed the Crawl and Walk posts, these posts are worth looking at if you have not started working on integrating security into your SDLC.

2008 Security Survey: We're Spending More, But Data's No Safer Than Last Year

An InformationWeek article indicates that companies are behind in implementing encryption to protect customer and employee data. The article also states:

"We had hoped that the ongoing parade of high-profile data losses would set most companies on the road to comprehensive privacy protection. So we were discouraged that the only actions to safeguard customer data that are used by more than half of companies are ... informing employees of standards and putting a privacy policy on the Web site. Fine steps, but they don't exclude the need for encryption (used by 34%) or privacy policy audits (25%). Amazingly, 11% say they have no privacy safeguards for customer data. Zip. Zero."

I think encryption is only one of the many steps you can take, an even better approach is to have risk management programs in place that allow you to understand what data you are collecting, and making sure you have a real business need to store it -- for example, why does your HR department even need all of the personal information they collect from a potential job applicant if they don't follow-up on 98% of the resumes they receive?

Understanding ways to mask and minimize the amount of data you collect, while still achieving the goal of the business should be the first priority of any organization's data owners.

Where is your Laptop?

Today's Chicago Tribune has a article which has to make one pause:

"More than 12,000 laptops are lost each week at U.S. airports, according to a study conducted for Dell by the Ponemon Institute, a research think tank. Only one-third of laptops lost and found in airports are reclaimed, the study said."

I guess that means that two thirds of the laptops are never missed by the persons that lost them? I wonder how much personal or customer information is on those?

Microsoft announces new SDL Website

Microsoft has recently launched a dedicated Security Development Lifecycle website at www.microsoft.com/sdl. This website will serve as the main online presence for all SDL related communications and resources from Microsoft. This website has links to various tools, including the SDL Blog which recently had a posting on SQL Injection Defense Tools.