Minimizing Risk with Secure Software and Processes

Microsoft has a dedicated Security Business Unit. Its goal is to ensure that all Microsoft products are secure by design, and that all systems are now hardened to improve security. It also helps ensure that deployments are secure, and that the right communication about security takes place with Microsoft’s customers and partners. The Security Business Unit, with over 200 dedicated employees, addresses customer needs with guidance, tools, and products to help them maintain a secure environment.
In early 2002, Microsoft took the unprecedented step of temporarily stopping the work of all Windows engineers, testers, product managers, others, —more than 8,500 people—while the company conducted intensive security training. Once the training was completed, the development teams analyzed the Windows code base to improve on existing security techniques and implement what was learned in training.
Later that year, Microsoft undertook similar security pushes for the .NET common language runtime, Microsoft Visual Studio.NET, Microsoft Office, Microsoft SQL Server™, Microsoft Exchange Server, Biztalk® Server, Systems Management Server, Host Integration Server, Commerce Server, and Content Management Server. These efforts, accompanied by design and test reviews, will continue through future versions of Microsoft products.
Vulnerabilities are neither the only nor the best measure of the security of a product. Software must provide the tools to mitigate common business risks rather than simply avoid creating them itself. One certification that gives a measure of how software reduces business risk is the Common Criteria Certification. This is a widely accepted standard for evaluating the security features and capabilities of information technology products with the intent of helping the customer select IT products that meet their security requirements.
The Linux operating system recently achieved certification from Common Criteria evaluation, but only at the Evaluation Assurance Level 2 (EAL2). Level 2 is defined as follows:
Requires the cooperation of the developer in terms of the delivery of design information and test results, but should not demand more effort on the part of the developer than is consistent with good commercial practice. As such it should not require a substantially increased investment of cost or time.
EAL2 is applicable in those circumstances where developers or users require a low to moderate level of independently assured security in the absence of ready availability of the complete development record. Such a situation may arise when securing legacy systems, or where access to the developer may be limited.
The Common Criteria Certification level 2 Linux certification is for a specific IBM hardware deployment where Suse is the only certified Linux distribution.
Source http://www.commoncriteria.org/docs/EALs.html#EAL2
Windows 2000 is certified at Evaluation Assurance Level 4, + Flaw Remediation, which is a more stringent evaluation (Windows 2003 Server is currently under evaluation). This level is the highest protection profile that is mutually recognized by all the participants in the Common Criteria arrangement.
EAL4 permits a developer to maximize assurance gained from positive security engineering based on good commercial development practices. Although rigorous, these practices do not require substantial specialist knowledge, skills, and other resources. EAL4 is the highest level at which it is likely to be economically feasible to retrofit to an existing product line. It is applicable in those circumstances where developers or users require a moderate to high level of independently assured security in conventional commodity TOEs (Target of Evaluation), and are prepared to incur additional security-specific engineering costs.
An EAL4 evaluation provides an analysis supported by the low-level design of the modules of the TOE, and a subset of the implementation. Testing is supported by an independent search for vulnerabilities. Development controls are supported by a life-cycle model, identification of tools, and automated configuration management.
|