Rhand Leal Security is something that everyone wants to have, but which no one ever wants to use. And this thought can bring a lot of problems.
Unless a system’s purpose is security related (e.g., firewall, access system, etc.), users pay little attention to how security is embedded in a product, and how it is tested to ensure it will work properly when needed. Critical systems of an airplane and a car accessed through entertainment systems, because of poor security implementation and verification, are two examples made public last year.
Today, I will present to you how ISO 27001 and ISO 27002 may help clarify that a system’s security, used by the organization itself or provided to clients as a service, should be taken into account during requirements specification and preparation of testing procedures.
What is a requirement? And why should I care about it?
A requirement is any statement elaborated in a way that makes it possible to use it to evaluate a result. For example, when you ask for “ice water,” you state the substance (water) and the temperature (ice) you want. The more detailed the requirement, the easier it is verify the results.
However, the more detailed the requirement, the more effort is needed to define and test it, and sometime this effort is neglected to avoid increasing costs – resulting in a lack of information needed to fulfill or verify the request. In the previous example, what is the quantity needed? How is the payment to be made? How will you show the “ice water” is acceptable?
And, if this simple request can become so complex, what about systems requirements? A lack of clear statements is what leads to poor product performance or security.
How to specify the security requirements
ISO 27001 control 14.1.1 (Information security requirements analysis and specification) states that requirements to protect information should be included in requirements for information systems. An example of a protection requirement is controlled access to information, according to clearance level.
To accomplish good requirement statements, ISO 27002 recommends:
Adoption of methods to identify requirements: systematic forms of identification may prevent some aspects from being forgotten or overlooked. Examples of methods are evaluation of policies and regulations, threat modeling, or incident reviews.
Results review by stakeholders: who is better fit to evaluate documented requirements than the ones who will be using the product? Choose persons in the various roles involved (e.g., final users, clients, system administrators, etc.).
Requirements evaluation according to information value to the business: proper security reflects the value the information / system has to the business. So, requirements should be prioritized according to the business purposes they are meant to protect.
Integration of requirements management in early stages of a project: the sooner the security is considered, the more options you will have to treat risky situations. Think about policies and the project development process itself.
Define criteria for product acceptance: at some point you must show that what was proposed to the system can really be accomplished, and that established procedures were correctly followed. And how can you do that? The main recommendation provided by ISO 27002 control 14.2.9 – System acceptance testing, is to define clear parameters and results to be met. These are the bases for the development of test procedures and routines, detailed in the next section.
Requirements testing
With a clear definition of what you should expect as results, you should consider how to ensure your system is complying with the requirements. According to ISO 27001, you can use A.14.2.8 (System security testing) to elaborate systematic activities to ensure the achievement of the previously defined acceptance criteria. More details can be found in ISO 27002, which recommends:
Establish which conditions trigger the need for a test: new systems are an obvious condition, but you should also consider updated systems, new versions, and components, since new or changed functionalities may bring risks to the system or the environment.
Establish systematic test routines: consider a routine of activities to be performed, with their respective inputs and outputs. This way you can ensure a test can be repeated and errors easily found.
Use multiple test levels: the first tests should be performed by the development team, to check the most basic operation requirements, and quickly correct simple code errors. For granting security assurance (the system works as expected and only as expected), independent tests should be done.
Realistic test environment: the more similar to the live environment, the better for identification of vulnerabilities and the reliability of the test. This point can be critical when the test involves the use of databases, since real data in tests can add risks by itself not related to the product. To minimize that, consider recommendations for control 14.3.1 (Protection of test data), avoiding the use of Personally Identifiable Information (PII), or using specific controls in the development process to strictly control the access to such databases.
Note that controls A.14.2.8 and A.14.2.9 differ from each other by the fact that A.14.2.8 covers the need for security testing, while A.14.2.9 covers which results the tests should achieve for a system to be accepted.
Good security = clear requirements + proper testing
Risks come from uncertainties. Every time you make a requirement without considering all relevant elements and interested parties, you add more, and unnecessary, uncertainty and risk to your business. Avoid that by using systematic practices and perform tests to ensure the results are what you planned. The benefits will come in the form of fewer incidents and better performance.
To learn more about the information security safeguards try this free online Security Awareness Training.
