I’ve read “Engineering Principles for Information Technology Security” so you don’t have to
My summary is as follows:
“(…) The security policy begins with the organization’s basic commitment to information security formulated as a general policy statement. The policy is then applied to all aspects of the system design or security solution.” [Principle 1]
Having said that, “[i]t is unwise to assume that developers know how to develop secure software. Therefore, ensure that developers are adequately trained in the development of secure software before developing the system.” [Principle 4]
The key word - “before”! That’s because “(…) [e]xperience has shown it to be both difficult and costly to implement security measures properly and successfully after a system has been developed, so it should be integrated fully into the system life-cycle process.” [Principle 2]
But keep in mind that “(…) elimination of all risk is not cost-effective. (…) In some cases, the benefits of a more secure system may not justify the direct and indirect costs. Benefits include more than just prevention of monetary loss; for example, controls may be essential for maintaining public trust and confidence. Direct costs include the cost of purchasing and installing a given technology; indirect costs include decreased system performance and additional training.” [Principle 5]
So how on earth should we know what’s cost-effective and what’s not? Well, that’s a job for “(…) a systems designer, architect, or security practitioner (…)”. They “(…) need to identify and address all competing operational needs. It may be necessary to modify or adjust (i.e., trade-off) security goals due to other operational requirements. In modifying or adjusting security goals, an acceptance of greater risk and cost may be inevitable.” [Principle 7]
“(…) Recognizing the uniqueness of each system allows a layered security strategy to be used – implementing lower assurance solutions with lower costs to protect less critical systems and higher assurance solutions only at the most critical areas.” [Principle 8]
Are there any best practices? Of course!
“(…) In general, external systems should be considered insecure. Until an external domain has been deemed “trusted,” system engineers, architects, and IT specialists should presume the security measures of an external system are different than those of a trusted internal system and design the system security features accordingly.” [Principle 6]
If only that could be so simple, right?
“(…) Where technology is used, hardware, firmware, and software should be designed and implemented so that a minimum number of system elements need to be trusted in order to maintain protection.” [Principle 25]
“Designers should recognize that in some instances it will not be possible to meet security goals with systems constructed entirely from COTS products. In such instances, it will be necessary to augment COTS with non-COTS mechanisms.” [Principle 10]
What the heck is COTS? Let me Google that for you… “Commercial off-the-shelf or commercially available off-the-shelf (COTS) products are packaged or canned (ready-made) hardware or software, which are adapted aftermarket to the needs of the purchasing organization, rather than the commissioning of custom-made, or bespoke, solutions.” [Wikipedia]
We said that “elimination of all risk is not cost-effective or even possible”. Thus, we should “[d]esign systems to limit or contain vulnerabilities. If a vulnerability does exist, damage can be limited or contained, allowing other information system elements to function properly.” [Principle 19]
Easier said than done! However, we can “ensure no single point of vulnerability” by implementing layered security. “(…) The need for layered protections is especially important when commercial-off-the-shelf (COTS) products are used. Practical experience has shown that the current state-of-the-art for security quality in COTS products does not provide a high degree of protection against sophisticated attacks. It is possible to help mitigate this situation by placing several controls in series, requiring additional work by attackers to accomplish their goals.” [Principle 16]
“(…) Examples of “attack” classes are: Passive monitoring, active network attacks, exploitation by insiders, attacks requiring physical access or proximity, and the insertion of backdoors and malicious code during software development and/or distribution.” [Principle 11]
Wait a second, I am an insider! - Yes, you are, that’s why your organization should implement least privilege.
“The concept of limiting access (…) is simply to provide no more authorizations than necessary to perform required functions. (…) Its goal is to reduce risk by limiting the number of people with access to critical system security controls; i.e., controlling who is allowed to enable or disable system security features or change the privileges of users or programs.” [Principle 26]
“(…) [I]t is better to have several administrators with limited access to security resources rather than one person with “super user” permissions. (…) Additionally, identify the roles/responsibilities that, for security purposes, should remain separate, this is commonly termed ‘separation of duties’.”
“(…) There are vulnerabilities that cannot be fixed, those that have not yet been fixed, those that are not known, and those that could be fixed but are not (…) to allow increased operational capabilities.” Thus, systems shouldn’t only be resistant to attacks or limit damage. They should also recover rapidly when attacks do occur! “(…) [S]ecure systems should have a well-defined status after failure, either to a secure failure state or via a recovery procedure to a known secure state. Organizations should establish detect and respond capabilities, manage single points of failure in their systems, and implement a reporting and response strategy.” [Principle 17]
Monitoring, recording, and periodically reviewing audit logs ensure proper functioning and identify unauthorized use of system resources. “As mission and business processes and the threat environment change, security requirements and technical protection methods must be updated. IT-related risks to the mission/business vary over time and undergo periodic assessment.“ [Principle 14]
“(…) In some cases, organizations may be required to disclose information obtained through auditing mechanisms to appropriate third parties (…)” - like during criminal investigation!
If all of the above sounds too much for you, please remember that I omit some of the principles which sound not so important or even artificial to me. However, security controls shouldn’t be overwhelming, quite opposite!
“The more difficult it is to maintain and operate a security control, the less effective that control is likely to be. Therefore, security controls should be designed to be consistent with the concept of operations and with ease-of-use as an important consideration.” [Principle 15]
“The more complex the mechanism, the more likely it may possess exploitable flaws. Simple mechanisms tend to have fewer exploitable flaws and require less maintenance. Further, because configuration management issues are simplified, updating or replacing a simple mechanism becomes a less intensive process.” [Principle 24]
It rings the bell - the fewer lines of code, the fewer places to introduce a bug, right?!
“Every security mechanism should support a security service or set of services, and every security service should support one or more security goals. Extra measures should not be implemented if they do not support a recognized service or security goal. Such mechanisms could add unneeded complexity to the system and are potential sources of additional vulnerabilities.” [Principle 27]