I was asked to deliver a keynote in Germany at the Security Transparent conference. Of course, I agreed. Transparency in security is one of the topics that is very close to my heart and I wish professionals in the industry not only talked about it more, but also applied it in practice.
Back in the old days, security through obscurity was one of the many defence layers security professionals were employing to protect against attackers. On the surface, it’s hard to argue with such a logic: the less the adversary knows about our systems, the less likely they are to find a vulnerability that can be exploited.
There are some disadvantages to this approach, however. For one, you now need to tightly control the access to the restricted information about the system to limit the possibility of leaking sensitive information about its design. But this also limits the scope for testing: if only a handful of people are allowed to inspect the system for security flaws, the chances of actually discovering them are greatly reduced, especially when it comes to complex systems. Cryptographers were among the first to realise this. One of Kerckhoff’s principles states that “a cryptosystem should be secure even if everything about the system, except the key, is public knowledge”.
Modern encryption algorithms are not only completely open to public, exposing them to intense scrutiny, but they have often been developed by public, as is the case, for example, with AES. If a vendor is boasting using their own proprietary encryption algorithm, I suggest giving them a wide berth.
Cryptography aside, you can approach transparency from many different angles: the way you handle personal data, respond to a security incident or work with your partners and suppliers. All of these and many more deserve attention of the security community. We need to move away from ambiguous privacy policies and the desire to save face by not disclosing a security breach affecting our customers or downplaying its impact.
The way you communicate internally and externally while enacting these changes within an organisation matters a lot, which is why I focused on this communication element while presenting at Security Transparent 2019. I also talked about friction between security and productivity and the need for better alignment between security and the business.
I shared some stories from behavioural economics, criminology and social psychology to demonstrate that challenges we are facing in information security are not always unique – we can often look at other seemingly unrelated fields to borrow and adjust what works for them. Applying lessons learned from other disciplines when it comes to transparency and understanding people is essential when designing security that works, especially if your aim is to move beyond compliance and be an enabler to the business.
Remember, people are employed to do a particular job: unless you’re hired as an information security specialist, your job is not to be an expert in security. In fact, badly designed and implemented security controls can prevent you from doing your job effectively by reducing your productivity.
After all, even Kerckhoff recognised the importance of context and fatigue that security can place on people. One of his lesser known principles states that “given the circumstances in which it is to be used, the system must be easy to use and should not be stressful to use or require its users to know and comply with a long list of rules”. He was a wise man indeed.
Identifying applicable threats is a good step to take before defining security controls your organisation should put in place. There are various techniques to help you with threat modelling but I wanted to give you some high-level pointers in this blog to get you started. Of course, all of these should be tailored to your specific business.
I find it useful to think about potential attacks as three broad categories:
1. Commoditised attacks. Usually not targeted and involve off-the-shelf-malware. Examples include:
- Ransomware (Maersk ransomware attack)
- Crypto mining (Hackers enlisted Tesla’s public cloud to mine cryptocurrency)
- Denial of service (Biggest-Ever DDoS Attack (1.35 Tbs) Hits Github Website)
2. Tailored attacks. As the name suggests, these are tailored and can vary in degree of sophistication. Examples include:
- Business email compromise (Online money transfer provider Xoom suffers multimillion-dollar fraud)
- Retail website breach (British Airways data breach)
- Data exfiltration (Private data of 500 million Marriott guests exposed in massive breach)
3. Accidental. Not every data breach is triggered by a malicious actor. Therefore, it is important to recognise that mistakes happen. Unfortunately sometimes they lead to undesired consequences, like the below:
- Human error (London Sexual Health Clinic Fined £180,000 for Data Breach)
- Insecure engineering practices (The NHS is blaming a coding error for 150,000 patients in England being involved in a data breach)
- Mishandling of data (Personal details of as many as 500 NHS doctors were exposed after an internal spreadsheet containing their details was published online)
Information security professionals can use the above examples in communications with their business stakeholders not to spread fear, but to present certain security challenges in context.
It’s often helpful to make it a bit more personal, defining specific threat actors, their target, motivation and impact on the business. Again, the below table serves as an example and can be used as a starting point for you define your own.
|Threat actor||Description||Motivation||Target||Impact on business|
|Organised crime||International hacking groups||Financial gain||Commercial data, personal data for identity fraud||Reputational damage, regulatory fines, loss of customer trust|
|Insider||Intentional or unintentional||Human error, grudge, financial gain||Intellectual property, commercial data||Destruction or alteration of information, theft of information, reputational damage, regulatory fines|
|Competitors||Espionage and sabotage||Competitive advantage||Intellectual property, commercial information||Disruption or destruction, theft of information, reputational damage, loss of customer|
|State-sponsored||Espionage||Political||Intellectual property, commercial data, personal data||Theft of information, reputational damage|
You can then use your understanding of assets and threats relevant to your company to identify security risks. For instance:
- Failure to comply with relevant regulation – revenue loss and reputational damage due to fines and unwanted media attention as a result of non-compliance with GDPR, PCI DSS, etc.
- Breach of personal data – regulatory fines, potential litigation and loss of customer trust due to accidental mishandling, external system compromise or insider threat leading to exposure of personal data of customers
- Disruption of operations – decreased productivity or inability to trade due to compromise of IT systems by malicious actor, denial of service attacks, sabotage or employee error
Again, feel free to use these as examples, but always tailor them based on what’s important you your business. It’s also worth remembering that this is not a one-off exercise. Tracking your assets, threats and risks should be part of your security management function and be incorporated in operational risk management and continuous improvement cycles.
This will allow you to demonstrate the value of security through pragmatic and prioritised security controls, focusing on protecting the most important assets, ensuring alignment to business strategy and embedding security into the business.
A company may divest its assets for a number of reasons: political, social or purely financial in order to free up resources to focus on core business. Regulators may also demand a divestment to prevent one company holding a monopoly. When such a decision is made, the security function can support the business by managing risks during this process. These risks not only include the obvious legal and regulatory compliance ones, but also risks related to business disruption and leaks of intellectual property or other sensitive information. Security teams can also help the business identify value adding opportunities through, for instance, saving costs on software licenses.
The scale of divestments vary and depend on the nature of the organisation: they can range from a single subsidiary to a whole division. Information usually accompanies physical assets, which opens up potential challenges with data governance when these assets change hands. The magnitude of such risks differ depending on specific conditions of the deal, for example:
- Number of assets is scope
- Criticality of assets
- Location of assets and applicable jurisdictions
In my experience, divestments are almost always associated with aggressive timelines for completion usually in the form of legally binding agreements. Therefore, as a security professional, the last thing you want to do is to slow down the process and prevent the business from meeting these timelines.
You need to balance this, however, with the risk exposure. It helps when the security team gets involved early to support the process from the start. All too often, however, the business can be asking for security sign-off after the finalisation of the deal. This can be disappointing, particularly when a number of data transfer requirements have already been violated.
So if you’re one of the lucky ones, and the business is asking for your advice on divesting securely, what should you tell them? What areas do you consider? Here are some examples to get you started:
- Information asset inventories and data maps. These might include data, software and infrastructure assets. You can’t help securely transfer something you don’t know exists. Start with establishing visibility and interdependencies.
- Access control. Who has access to what? Do they need that access? Will they need that access in the future? Segregation of duties and least privilege principles are not just abstract philosophical concepts – they have real applications when it comes to divestments.
- Consider legal and regulatory requirements when it comes to data asset transfer, retention and disposal. Involve your legal team, but don’t forget about technical controls, like encryption and secure data wipes.
- Availability of skilled resource and mature IT function on the ‘buy’ side. Remember, whoever is buying the assets must have their infrastructure ready to support the acquisition and integration of new assets. Despite being perceived as a ‘buyer’s problem’, risks like that can negatively impact the overall project and should be considered.
All in all, the divestment process can be challenging but the early integration of security professionals ensures the appropriate oversight is given to all relevant areas for a smooth transfer to the buyer.
IT Governance Publishing named me the author of the month and kindly provided a 20% discount on my book.
There’s an interview available in a form of a podcast, where I discuss the most significant challenges related to change management and organisational culture; the common causes of a poor security culture my advice for improving the information security culture in your organisation.
ITGP also made one of the chapters of the audio version of my book available for free – I hope you enjoy it!
If you would rather listen to an audio while driving, exercising or commuting, this version is for you. The book has intentionally been kept to the point which means you can finish the audio in slightly over two hours. The fact that it costs the equivalent of two cups of coffee is an added benefit.
I know I’m slightly biased here, but I highly recommend it!
To support my firm’s corporate and social responsibility efforts, I volunteered to help NSPCC, a charity working in child protection, understand the Internet of Toys and its security and privacy implications.
I hope the efforts in this area will result in better policymaking and raise awareness among children and parents about the risks and threats posed by connected devices.
Toys are different from other connected devices not only because how they are normally used, but also who uses them.
For example, children may tell secrets to their toys, sharing particularly sensitive information with them. This, combined with often insufficient security considerations by the manufacturers, may be a cause for concern.
Apart from helping NSPCC in creating campaign materials and educating the staff on the threat landscape, we were able to suggest a high-level framework to assess the security of a connected toy, consisting of parental control, privacy and technology security considerations.
Let’s talk about applying the SABSA framework to design an architecture that would solve a specific business problem. In this blog post I’ll be using a fictitious example of a public sector entity aiming to roll-out an accommodation booking service for tourists visiting the country.
To ensure that security meets the needs of the business we’re going to go through the layers of the SABSA architecture from top to bottom.
Start by reading your company’s business strategy, goals and values, have a look at the annual report. Getting the business level attributes from these documents should be straightforward. There’s no need to invent anything new – business stakeholders have already defined what’s important to them.
Every single word in these documents has been reviewed and changed potentially hundreds of times. Therefore, there’s usually a good level of buy-in on the vision. Simply use the same language for your business level attributes.
After analysing the strategy of my fictitious public sector client I’m going to settle for the following attributes: Stable, Respected, Trusted, Reputable, Sustainable, Competitive. Detailed definitions for these attributes are agreed with the business stakeholders.
Next step is to link these to the broader objectives for technology. Your CIO or CTO might be able to assist with these. In my example, the Technology department has already done the hard job of translating high-level business requirements into a set of IT objectives. Your task is just distill these into attributes:
Now it’s up to you to define security attributes based on the Technology and Infrastructure attributes above. The examples might be attributes like Available, Confidential, Access-Controlled and so on.
The next step would be to highlight or define relationships between attributes on each level:
These attributes show how security supports the business and allows for two-way tracebility of requirements. It can be used for risk management, assurance and architecture projects.
Back to our case study. Let’s consider a specific example of developing a hotel booking application for a public sector client we’ve started out with. To simplify the scenario, we will limit the application functionality requirements to the following list:
|P001||Register Accommodation||Enable the registration of temporary accommodations available|
|P002||Update Availability||Enable accommodation managers to update availability status|
|P003||Search Availability||Allow international travellers to search and identify available accommodation|
|P004||Book Accommodation||Allow international travellers to book accommodation|
|P005||Link to other departments||Allow international travellers to link to other departments and agencies such as the immigration or security services (re-direct)|
And here is how the process map would look like:
There are a number of stakeholders involved within the government serving international travellers’ requests. Tourists can access Immigration Services to get information on visa requirements and Security Services for safety advice. The application itself is owned by the Ministry of Tourism which acts as the “face” of this interaction and provides access to Tourist Board approved options. External accommodation (e.g. hotel chains) register and update their offers on the government’s website.
The infrastructure is outsourced to an external cloud service provider and there are mobile applications available, but these details are irrelevant for the current abstraction level.
From the Trust Modelling perspective, the relationship will look like this:
Subdomain policy is derived from, and compliant with, super domain but has specialised local interpretation authorised by super domain authority. The government bodies act as Policy Authorities (PA) owning the overall risk of the interaction.
At this stage we might want to re-visit some of the attributes we defined previously to potentially narrow them down to only the ones applicable to the process flows in scope. We will focus on making sure the transactions are trusted:
Let’s overlay applicable attributes over process flows to understand requirements for security:
Now it’s time to go down a level and step into more detailed Designer’s View. Remember requirement “P004 – Book Accommodation” I’ve mentioned above? Below is the information flow for this transaction. In most cases, someone else would’ve drawn these for you.
With security attributes applied (the direction of orange arrows define the expectation of a particular attribute being met):
These are the exact attributes we identified as relevant for this transaction on the business process map above. It’s ok if you uncover additional security attributes at this stage. If that’s the case, feel free to add them retrospectively to your business process map at the Conceptual Architecture level.
After the exercise above is completed for each interaction, it’s time to go down to the Physical Architecture level and define specific security services for each attribute for every transaction:
At the Component Architecture level, it’s important to define solution-specific mechanisms, components and activities for each security service above. Here is a simplified example for confidentiality and integrity protection for data at rest and in-transit:
|Service||Physical mechanism||Component brands, tools, products or technical standards||Service Management activities required to manage the solution through-life|
|Message confidentiality protection||Message encryption||IPSec VPN||Key management, Configuration Management, Change management|
|Stored data confidentiality protection||Data encryption||AES 256 Disk Encryption||Key management, Configuration Management, Change management|
|Message integrity protection||Checksum||SHA 256 Hash||Key management, Configuration Management, Change management|
|Stored data integrity protection||Checksum||SHA 256 Hash||Key management, Configuration Management, Change management|
As you can see, every specific security mechanism and component is now directly and traceable linked to business requirements. And that’s one of the ways you demonstrate the value of security using the SABSA framework.