|
IT Security Engineering
|
When it comes to security, experience matters. Vulnerabilities are introduced into products both by failing to follow through on security practices and from subtle mistakes. ASL has developers with decades of secure system development experience, which addresses the first problem. ASL has evaluators with independent analysis and testing experience, which addresses the second problem. We've got more than book learning. Engineers often rate component failure in terms of probabilities, and system failure rates as products of component failure rates, but this formula doesn't apply when facing malicious attackers who often manipulate component failure modes to maximize their opportunity for success. The engineer's focus on the correct use of a system and perhaps the ways in which honest users might err in using it, is of little use in protecting against malicious attacks. ASL's experience with IT product evaluation gives us an attacker's perspective on product and system security and a nose for vulnerabilities. Architecture is important to achieving a secure design that can be evaluated. Complexity often undermines otherwise secure designs, making them more difficult to implement correctly, introducing errors, making testing more difficult, and making it harder to analyze for correctness. This adds expense to product certification activities, such as those provided by the Common Criteria, and lowers the level of assurance that can be achieved. ASL can help develop a secure design and achieve a robust implementation. Our experience in product evaluation and our attacker's perspective honed by years of analyzing and breaking secure systems can augment your design team and result in creating secure designs that can be efficiently certified. Our areas of expertise are:
|
MILS Overview The Multiple Independent Levels of Security (MILS) architecture for embedded operating systems was developed at NSA in reaction to the economic failures of high assurance evaluations of standard model kernels during the 1980s. The MILS kernel is kept simple by relocating all but the bare essentials into higher levels (rings). What remains is kernel self-protection, the isolation of partitions from each other, static data flows between partitions, a static memory model, and fixed scheduling. File systems, devices, device drivers, and many other of the usual kernel services are moved to user space, resulting in a kernel that is small enough to be economically proven correct using formal methods. The MILS design and security criteria has been captured in the Separation Kernel Protection Profile. ASL engineers have been helping vendors implement MILS systems that are certifiable under the CC for several years. Contact ASL to find out how we can help you implement MILS or use MILS components in your system. |
