One of the biggest problem that most IT security experts around the world have is the fact that IT security is never taken seriously until a security incident takes place. After that, management boards start being interested in IT security. However, these managers see security not through the eyes of an expert, but through the eyes of a business man. They need to measure, to plan and probably most important of all, they need to know the costs. An easier way to talk security with management is to define security as a manager.
SMART is a mnemonic with many accepted meanings, but in this article it stands for: Specific, Measurable, Achievable, Relevant, Time-oriented. The term is coming originally from project management where it is used to set objectives (called Key Performance Indicators – KPIs) and to track them. For security specialists it is important to be able to set and track KPIs for the goals they want to achieve when evaluating, designing, implementing security solutions or when doing risk assessment.
Presenting SMART goals to a management board can make security goals be easier to understand and ... to approve.
While on the first view these terms are overlapping, they are actually very tight interconnected and they are influencing each other.
Specific means that there is a need to have a dedicated goal instead of a general goal when trying to define and implement security. Since 100% security (also called 360 degrees security ) is in reality never possible (which unfortunately many sell and even more buy), it is very important to define security goals that address a particular set of problems and not all possible problems. For example, when defining the goals, the following have to be defined:
- what is to be secured
- against what is the objective secured
- what happens if the security goals are not met (the risks against we try to provide security)
- who or what should provide the security
- in which way will be the security provided
To have a measurable security goal or strategy, you need to be able to answer the question: how will I know that I accomplished the goal? If a goal is not measurable, it is probably not specific enough, or it is not attainable, relevant or time oriented (see below the definitions - the terms are interconnected and are influencing each other).
You need to define some metrics for the topics defined in the scope so that you can measure and track their achievement. For example, if you plan the security of a web portal, you will know that you achieved your goal of securing the web application if:
- no unauthenticated user is allowed to access the portal
- a PEN test on the portal shows zero vulnerabilities
- your portal survives a DDoS
This term is probably the most complicated one to be addressed because it requires a lot of experience in order to be done right. In theory, everything is achievable, but in practice we all know that some goals are more realistic than others. The most common constrains that can influence a security goal can be the budget, time, resources, scope and many others. To make sure that your goals are achievable, you should be able to answer the question: how exactly can this goal be achieved? Or, do I have what I need to achieve this goal?
It is not enough only to define goals (e.g. use defense in depth), you need to be able to achieve them(the exact steps how to implement this good security principle).
A security goal is relevant if it makes sense to be implemented and if it really applies to your problem. This means that there is some value which must be secured and that the cost of protecting it is less than the value (positive ROI) to be protected. Easier said than done since you can’t easily measure credibility, trust or market share - which usually have to suffer when a company has a security incident . You can’t secure everything, or protect against any possible risk, so it is imperative to choose the goals that really matter (sorry for those who sell security policies). A security goal can have all other attributes mentioned above, but it might lack relevance, so it is not worth to be implemented.
When you make risk assessment, you need to describe all risks and make them measurable, so that you can assess how important they are. So, measurability might help to determine if a goal is relevant (if it is worth securing). A multi-layer security approach will help you to identify relevant goals for the respective layer. If you partition, you can see the problems of a layer easier than all the problems of the entire system. Relevancy should also be searched in the solutions meant to achieve a security goal. For example, if you see a lot of attacks on a certain open port which you know that nobody uses, it makes no sense to install an application firewall to filter the access to that port if you can simply close the port (hardening a system).
In security, we are always confronted with time. Time is always critical, because if securing something takes too much time to implement, it might be not worth securing it anymore (think of intellectual property). If you were to secure a building, one thing is to close the door with a key, and another thing is to take the time and do an extensive analysis and then install expensive security systems, video surveillance, set a human guard, etc. But, it might be that all you need is to close the door, because this would solve the emergency. Time can make also a goal to become irrelevant - if you can’t secure your web application until the first users register, it might be too late after that (this doesn’t mean that you shouldn’t secure it after that). It can also make a goal unachievable – some operations need time to be implemented and if you don’t have that time, you can’t achieve your goal.
You goals are time-oriented if you can answer: When should it start? When it should end?
(ISC)2 CSSLP, CompTIA Project+, Security+