System Security

Unlike typical system requirements, System Security places constraints on what computers are not supposed to do. For example, a typical software application, such as a word processor, has requirements such as producing documents. System Security, on the other hand, constrains such software to not do something malicious, such as erase other files.

Increasing a system's security involves improving security at both the Operating System and Application levels.

Operating System Security

One of the first decisions in ensuring system security is choosing the operating system. All operating systems are not created equal, and a balance must be met between convenience, features, and safety.

Most operating systems are not, and will never be certified Orange Book A-1 for the simple reason that the application and data do not warrant the extra sacrifices. In many scenarios, the operating system is dictated by the application that is to be used on the system.

For this reason, most operating system security occurs by reaction, instead of the security-by-design approach. A method to mitigate the damages caused by reactionary security, is to limit the technologies to only those necessary to meet the mission of the system.

Application-Level Security

One must not only apply security restrictions to the operating system, but also to applications. An application's purpose must be well defined and meet the overall mission of any enterprise system. Features that are not needed, or unused, should be disabled to ensure that the application is minimally exposed to misuse.

The most common weakness found in applications is incorrect data handling. Assumptions are often made as to the type, quantity, and integrity of data that is received from external sources (such as User Interfaces, SOAP, RPC, etc.). These mistakes can yield security concerns from the minor (duplicate information, unauthorized data retrieval) to the major (identify theft or spoofing, system compromise). Application security should be considered during all levels of a system life-cycle: creation, implementation, deployment, and maintenance.

Fail-Over or Fail-Secure?

Often overlooked, an appropriate security policy should include how events should be handled after a failure. Should the system continue to operate in a degraded manner, or should the system fail until the components can be verified.

In security-intensive systems, protection of confidential information is of the utmost importance. In such a system, failing "secure" is of the utmost importance to ensure that no data has been compromised. In such a configuration, systems may even be removed from operation to ensure no unauthorized or unintended access can occur. While the most secure, this method also causes the greatest impact for users of the system, sometime grinding work to a halt.

For less sensitive systems, uptime might be of more importance. In such scenarios, backup systems maybe utilized to ensure the maximum functionality for users. Sometimes these systems can run in a "degraded" mode, that allows for continued operation, but with somewhat less functionality. An example would be to disable all scripting on a public webserver, so that static pages may continue to operate, but executable scripts would be prevented from running.

Contact Us

Email: - This is a fake email to prevent spam. Please turn Javascript on to see actual email.