The Security Manifesto gets some Principles...
Any manifesto is merely a starting point, giving the reader what is known as the "10-word answer". It sounds impressive, but doesn't provide any details as to how the lofty goals the manifesto might outline can be achieved. The Security Manifesto is such:
We MUST uncover effective ways of securing organisations by doing it and helping others do it.
Through this work we value:
security by design over security is added
security is learned over security is bought
everyone is responsible over IT is responsible
following a secure usable process over following a security process
What is needed are details of how this might be achieved - the Security Principles.
Our highest priority is to satisfy the users through early and continuous delivery of a secure organisation. With data privacy laws now firmly established in many countries (along with severe fines) there is today a financial motivation to achieve a secure organisation. As well, the reputation damage to an organisation can also add to the loss due to poor security. Today, if something goes wrong, it will appear in some form of online news article, blog or social media update. The Internet also gives our systems access to a wide range of nefarious characters. Users (whether internal users or external clients and customers) must be sure their information is secure, and there is a legal (and hence financial) obligation the organisation secures it's data assets.
Welcome newly identified vulnerabilities. A long vulnerability list is better, as vulnerabilities still exist even when they are NOT identified. Vulnerabilities could be anything from an open port on a server, a document on a desk containing confidential information or a user who clicks on a link in an email. Vulnerabilities are tied to operating systems, applications, communications protocols, databases - in fact anything running on a computer. But not only that - vulnerabilities can exist in procedures as mundane as internal mail handling and document printing. They can also exist in people - answering the phone, email, or a conversation with someone in a bar. Importantly, a vulnerability is a weakness which could be exploited by an attacker. Vulnerabilities must be identified, as if a vulnerability exists that is not identified, it might be a malicious user that finds it. It's better to have a long list of mitigated vulnerabilities than a short list. An organisation has potentially hundreds of vulnerabilities the need protecting or eliminating. An attacker may only need to find one...
To identify vulnerabilities, the digital and non-digital assets must be identified and understood. An attacker might attempt to exploit a vulnerability to gain access to an asset. Anything that has value and supports the smooth operating of an organisation can be considered an asset, being roughly categorised into digital and non-digital assets. Assets are valued based on future revenue generated from the asset, value to a competitor, the time and effort needed to recreate the asset or fines/ penalties for loss or damage to the asset. The asset can then be further categorised based on it's sensitivity and related value (Public/ Confidential/ Highly Confidential/ Private/ Secret). Procedures must then be written surrounding the classifications and the assets contained within the classification, and those procedures checked for vulnerabilities.
Identification and mitigation of vulnerabilities to the organisation and user assets is the primary measure of progress. Bringing the previous principles together, progress in securing the organisation can be measured using the protection of assets by mitigating or eliminating vulnerabilities. Vulnerability identification and mitigation can become an important KPI for monitoring.
All security is based around technology, processes and people. As mentioned earlier, security isn't based on techie nerds doing stuff to computers. Security is all encompassing, looking at the organisation's procedures and vulnerabilities that could be exploited in them. People as well can be vulnerable and as individuals we must all acknowledge that these vulnerabilities exist. Anyone can roll their eyes and make comments after an attack has been detected, reacted to and recovered from. But, a large number of attacks rely on people being vulnerable. A mistake often made is to think of security only as a web-based technical issue. A phishing attack needs a user to click on the link, after all.
Everyone in the organisation is responsibly for security. Certain levels in an organisation can sometimes think security doesn't apply to them. In fact, these high-level people could be the target. Attacks such as spear-phishing (a specific directed attack against an individual) and whaling (a phishing attack aiming at high-level employees) can target these staff. These high-level staff are often publicly known - their photos and signatures are on public marketing materials and annual company reports, and often they might have blogs or media releases. Just the same, low-level staff may have access to sensitive information and may be susceptible to compromise with anything from a simple phishing attack to their own personalised spear-phishing attack. We all must be conscious of the information we put online and who could have access to this.
Some individuals have the security mindset. Encourage them to learn and develop their talent. People with the security mindset see the world differently. They are people who have hobbies like card tricks, magic or lock-picking. They walk into shops and can describe how they might shop-lift, or vote in elections and think how they might vote twice (without doing it, of course). And they are really good at escape rooms! The ability to see the world differently is a valued trait that, if identified, should be encouraged and nurtured. It becomes a huge advantage, with appropriate training, to identifying and mitigating security vulnerabilities.
Security should be designed into the organisation with awareness and training. Security should be designed into processes integrating privacy, simplicity and usability. Security should be designed into systems using secure architecture, secure coding practices and security principles. In designing any application, system, network infrastructure or process, security should be designed in. A big misconception is that security can be bolted on later. The organisation can be trained with specific, effective, directed training on current threats to the organisation. Processes should be created to protect sensitive data, but also be simple to follow and user-friendly. For example, a password rule asking for passwords with random upper/ lower/ number/ special characters are more difficult to remember than a long passphrase and give no additional security. Security should be based on secure coding and architecture practices outlined by IEEE, OWASP and/or SANS.
Security is an end-to-end process, not just an event, an application or a department. Security is iterative, continuing while the organisation exists. The principles and processes of security must be embedded into the organisation as a whole and specifically its projects. If security is embedded into an organisation, all staff will participate in security. It will form part of each process, and be specific to every staff role and member. And it will continue to be applied and updated based on the risks, vulnerabilities and threats the organisation and it's staff face.
At regular intervals, the security team meets to share information and reflect on how to become more effective, then adjust their behaviour accordingly. Collaboration is important for gaining new insights on vulnerabilities and threats. There is a wealth of knowledge existing on security vulnerabilities, threats and methods - so much so that it can be difficult to keep up. Security staff should look for blogs, conferences, and special interest groups to which they can subscribe. And, upon learning new information, be ready to share this with relevant staff. Information repositories should be kept of these updates to allow all security staff to share knowledge.
Least privilege and data privacy should cover all activities, processes and systems throughout the organisation. Many attacks originate internally. Yet many people only fear the movie image of organised criminals, a young disgruntled genius in a darkened room surrounded by empty energy drink cans, or a room filled with the uniforms of a foreign military. Rarely do they think of an extra email address added to a mail group, or an extra printed copy of a report dropped into the post, or a quick WhatsApp call to a friend. We often grant a level of trust based on the fact a person works for the organisation. That individual may not feel the same loyalty that other staff might feel. Whether the threat in internal or external, it's still a threat. Both internal and external threats require different security measures to mitigate.
Security is built through knowledge. All organisation need security training specific to the organisation’s assets, vulnerabilities and threats. Security staff need further specific training. Think of the "mandatory security training" specified in many organisations. All this so-called training achieves is a tick in a box to ensure that security training is completed for another year. The training is usually a third-party generic set of slides or basic e-learning, purchased by people without the security mindset. This material doesn't change based on organisational risk, threats or vulnerabilities, and must be completed by all staff (except the bosses, of course). So each YEAR, everyone thinks of security once, for 20 minutes, and must pass the same test with basic questions (at least get most of the questions right). Without specific training based on roles, and general training for all staff based on the specific organisation risks, vulnerabilities and threats, all that's achieved is a tick in a box on a list, and 20 minutes multiplied by the number of staff's time wasted.