Microsoft releases Cross Site Scripting Security reference.
Cross-site scripting attacks are on the rise because they are easy for attackers to craft and execute. In addition, they allow attackers to gather the most valuable content (user data) rapidly and in a manner that can easily go unnoticed by the user and often the Web site or application itself. As XSS attacks continue, it is imperative that development organizations prepare themselves with the solutions needed to rapidly address the problems as they occur. It is equally important that long-term solutions including security policies/requirements are in place to design, implement, verify, and release code that proactively protects your customers from XSS attacks.
Microsoft has released another document as part of their SDLC document library. This time is a 21 page document titled “Quick Security Reference : Cross Site Scripting”. The scope of this document is to increase awareness of XSS Vulnerabilities to each persona involved in software development. In particular Microsoft identifies four different roles: Business decision maker, architect, developer and tester.
Quick Security Reference Cross Site Scripting Reference also includes results of a basic survey of software companies that have established practices for fixing vulnerabilities that lead to attacks approximate that the costs associated with remediating a Web site that has encountered XSS like attack is around 40-man-hours per incident. That cost combined with the cost of hiring or training engineer to address the problem (~100$/hour) and the average number of seven XSS (or similar) exploitable vulnerabilities per Web site brings the total estimated cost to $28,000 to fix each problem reactively.
Figure 1. “12 Web application vulnerabilities between January 2006 and June 2007” shows XSS at the top of the ladder leaving no doubt that XSS is definitely one of the most exploited vulnerabilities in today applications.
Each persona is then introduced to different topics related to XSS, strictly related to their role and responsibilities. An architect will be more involved in Input Validation Rules, Output encoding strategies, Future Design Considerations rather then Identifying Untrusted Input and Writing Secure Code just to mention few. Useful insights on how to identify and classify an XSS type vulnerability (Reflected, Stored, Local) and software development best practices are also part of the document.
In conclusion; Software developers may find this document surprisingly useful as it covers almost everything they need to know in order to prevent, discover, mitigate and fix XSS vulnerabilities.
Microsoft security considerations for clients and cloud applications
Microsoft is about to release its new Cloud computing product named Windows Azure by January 2010. Azure will provide a new Cloud Computing option to software vendors and application developers.
With that said, Microsoft has released on the 13th of November a six paged document “Security Considerations for Client and Cloud Applications” via their Secure Development Lifecycle website. Surprisingly, the document doesn’t actually includes any advice for application developers nor for IT Managers considering moving their applications on the cloud.
It’s more just a “Look. Here how we do cloud computing at Microsoft and, as you can see we do actually care about security. So pick us up” document.
The only interesting part of the document which is worth mentioning is an overview of what the Operational Services Security and Compliance team within Microsoft does. OSSC team works across the operation, product, and service delivery teams and with internal and external auditors to ensure compliance with the relevant standards and regulatory obligations.
The following list presents an overview of some of the audits and assessments that the Microsoft cloud environment must undergo on a regular basis:
- Payment Card Industry Data Security Standard (PCI-DSS). This standard requires an annual review and validation of the security controls related to credit card transactions.
- Media Ratings Council. This relates to the integrity of advertising system data generation and processing.
- Sarbanes-Oxley (SOX). This legislation requires that selected systems are audited annually to validate compliance with key processes related to financial reporting integrity.
- Health Insurance Portability and Accountability Act (HIPAA). This act specifies privacy, security, and disaster recovery guidelines for the electronic storage of health records.
- Internal audit and privacy assessments. Assessments occur throughout a given year.
After analyzing all of these requirements, Microsoft determined that many of the audits and assessments required an evaluation of the same operational controls and processes. Recognizing the significant opportunity to eliminate redundant efforts, streamline processes, and proactively manage compliance expectations in a more comprehensive manner, the OSSC team developed a comprehensive compliance framework. This framework and associated processes follow the five-step methodology represented in the following illustration.
-
Identify and integrate requirements. Define the scope and applicable controls. Standard operating procedures (SOPs) and process documents are gathered and reviewed.
-
Assess and remediate gaps. Identify and remediate gaps in process or technology controls.
-
Test effectiveness and assess risk. Measure and report on the effectiveness of controls.
-
Attain certifications and attestations. Engage with third-party certification authorities and auditors.
-
Improve and optimize. Assess and document the root cause of any noncompliance, and then track the remediation process. This phase also involves continuing to optimize controls across security domains to generate efficiencies in passing future audit and certification reviews.
Different Applications different level of security required
The security required will vary, depending on the type of system. For example, a government system dealing with millions of social security numbers will have much stronger requirements than a standard business application. Microsoft classifies systems as low, moderate, or high business impact to help determine security requirements and the strength of security features that they must provide. The categories take into account the relative potential for financial and reputational damage if the asset was involved in a security incident. For example, data assets falling into the moderate impact category are subject to encryption requirements when they reside on removable media or when they are involved in external network transfers. Data in the high impact category, in addition to moderate impact requirements, is subject to encryption requirements for storage and for internal system and network transfers.
For all cloud services that Microsoft offers, the documentation provided to users will always state what is protected and how it is protected. For example, users who choose to host their applications “in the cloud” may want to have their applications and processing protected from those of other users. For these users, Microsoft is committed to providing this level of protection. Additional security feature and protection requirements will vary from user to user, and from application to application, depending on data sensitivity and on applicable laws and regulations. Microsoft will be transparent about the strength and applicability of the security protections that its cloud services offer so that users will know what security features and processes are available, and will be able to determine how Microsoft will protect their data and processing. The information provided will enable users to evaluate the suitability of Microsoft’s cloud platform for their security requirements and to make informed decisions about their use of cloud services.
