ArchiMate modelling language is one of the The Open Group enterprise architecture standards. It is aligned with TOGAF and aims to help architects (and other interested parties) understand the impact of design choices and changes.
Here I would like to build on the foundation we’ve laid while discussing SABSA architecture and design case study and share and example of using the Archi tool to model security architecture using the SABSA framework.
Let’s say ACME Corp asked us to help them with their security architecture. Where do we start?
As described in my previous blog, let’s establish Contextual Architecture.
Using Archi, I select Principles (can be found in Motivation section) for attributes and define composition relationship between elements (e.g. ACME Corp is composed of Cost-effective, Reputable and many other attributes that hopefully define the business).
Here and below I’ll be using a simplified example just to illustrate a point – you will have many more attributes in practice.
From reading company annual reports and talking to business stakeholders we can start identifying business drivers of ACME Corp. We can them map these business drivers to attributes. Below is an illustration of mapping a business driver Generate revenue (Driver element) to the attribute Cost-effective using Influence relation, as business drivers influence attributes.
On the Conceptual architecture level we need to start defining lower level attributes. For example, Cost-effective is composed (Composition relation) of Available and Business-driven
Remember that you can provide definitions of your attributes in the element’s properties (Main section). In this example I’m defining Available as Service should be uninterrupted. You are also encouraged to establish a measurement approach for each attribute. You can see above that Uptime is the main KPI for availability. It’s a hard measure where we monitor the percentage of time system is available compared to what is specified in the SLA.
Logical level provides an insight into what capabilities enable the attributes. In the example below, Available is realised (Realsisation relation) by Backup capability which in turn is comprised of Synchronous and Asynchronous backup capabilities (Composition relation).
Archi tool allows us to model SABSA Physical Architecture view by describing services, events, processes, interfaces, functions and other elements of the TOGAF Technology layer.
Below is a simplified example of describing the Asynchronous backup capability.
Asynchronous backup is being realised by Backup manager application service (reaalisation relation). Backup store is a data object that is being accessed by the Backup manager (access relation).
You can be quite detailed here and that’s where Archi tool can add a lot of value. But to keep things simple, I’m going to leave it at that. You can decompose elements into services and function, group them together and even go lower describing actual technology solutions on SABSA Component architecture level.
The real question is: what do you do with all of this?
My answer is simple: visualise.
Archi let’s you switch into the Visualiser mode and create graphs bringing all your hard work together. Playing with depth (6 in the example above) you can analyse the architecture and ensure traceability: you can see and, more importantly, demonstrate to your business stakeholders how a particular technology solution contributes to the overall business objective.
In addition, the Validator allows you to see the elements that are orphaned, i.e. not related to any other element. You then have the ability to rectify this and introduce a relationship or discontinue the capability (otherwise, why are you paying for something that is not in use?).
If you followed the steps above, the tool, despite being free, actually does a lot of the heavy lifting for you and automatically adjusts the models and graphs if changes to the architecture are introduced.
Now it’s your turn to try out Archi for SABSA architecture. Good luck!
I would like to thank Chul Choi for outlining the above technique.
Telling stories is one of the best ways to get your ideas across, especially when your audience is not technical. Therefore, as an architect, you might want to communicate in a way that can be easily understood by others.
TOGAF, for example, encourages enterprise architects to develop Business Scenarios. But what if you want to represent your concepts visually? The solution might lie in using a modelling language that meets this requirement.
ArchiMate is an open standard for such a language that supports enterprise architects in the documenting and analysing of architecture. Full alignment with aforementioned TOGAF is an added bonus.
The ArchiMate mimics constructs of the English language i.e. it has a subject, an object and a verb that refer to active, passive and behavior (action) aspects respectively. It employs these constructs to model business architecture.
To illustrate this, let’s model a specific business process using ArchiMate. Similarly to the example described in one of the whitepapers, let’s consider a stock trader registering an order on the exchange as part of the overall Place Order process.
Thinking back to the English language parallel, what does this sentence tell us? In other words, who is doing what to what?
In this scenario, a Trader (subject) places (verb) the order (object).
The diagram below illustrates how this might look like when modelled in ArchiMate.
‘Trader’, being an active element is modelled as Business Role, ‘Place Order’ as a behavior (action) element is represented as Business Process and the passive ‘Order’ itself is modelled as Business Object.
The relationship between elements carry meaning in ArchiMate too. In our example, Assign relation is used to model the ‘Trader’ performing the ‘Place Order’ action. Contrary, the interaction between ‘Place Order’ and ‘Order’ is modelled using Access relation to illustrate that the the Business Process creates the Business Object.
To put all of this into practice, you can use the Archi modelling toolkit. It’s free, open-source and support multiple platforms.
In fact, I used it to illustrate the scenario above, but it can do much more. For example, I talk about modelling SABSA architecture using ArchiMate in my other blog.
When building a house you would not consider starting the planning, and certainly not the build itself, without the guidance of an architect. Throughout this process you would use a number of experts such as plumbers, electricians and carpenters. If each individual expert was given a blank piece of paper to design and implement their aspect of the property with no collaboration with the other specialists and no architectural blueprint, then it’s likely the house would be difficult and costly to maintain, look unattractive and not be easy to live in. It’s highly probable that the installation of such aspects would not be in time with each other, therefore causing problems at a later stage when, for example, the plastering has been completed before the wiring is complete.
This analogy can be applied to security architecture, with many companies implementing different systems at different times with little consideration of how other experts will implement their ideas, often without realising they are doing it. This, like the house build, will impact on the overarching effectiveness of the security strategy and will in turn impact employees, clients and the success of the company.
For both of the above, an understanding of the baseline requirements, how these may change in the future and overall framework is essential for a successful project. Over time, building regulations and practices have evolved to help the house building process and we see the same in the security domain; with industry standards being developed and shared to help overcome some of these challenges.
The approach I use when helping clients with their security architecture is outlined below.
I begin by understanding the business, gathering requirements and analysing risks. Defining current and target states leads to assessing the gaps between them and developing the roadmap that aims to close these gaps.
I prefer to start the security architecture development cycle from the top by defining security strategy and outlining how lower levels of the architecture support it, linking them to business objectives. But this approach is adjusted based on the specific needs.
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 traceability 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.
I’ve recently passed my AWS Certified Solutions Architect – Associate exam. In this blog I would like to share some preparation tips that would help you ace it.
Not only practice makes perfect, some hands-on experience is also a prerequisite for the exam. So there is really no way around that! But what if you didn’t have a chance to use your skills on a real-world project yet? No problem! AWS gives you a opportunity to learn how their cloud components work through AWS Free Tier. For one year, you can use Amazon EC2 , Amazon S3, Amazon RDS, AWS IoT and many more free of charge,
You want more guidance? Qwiklabs developed a set of labs that specifically designed to help you prepare for this exam. For a small price, you can complete exercises without even requiring an AWS account or signing up for Free Tier.
I recommend studying AWS Whitepapers to broaden your technical understanding. If you are short on time, focus on these:
- Overview of Amazon Web Services
- Architecting for the Cloud: AWS Best Practices
- How AWS Pricing Works
- Compare AWS Support Plans
AWS developed a free self-paced Cloud Practitioner Essential course, to help you develop an overall understanding of the AWS Cloud. You will learn basic cloud concepts and AWS services, security, architecture, pricing, and support.
There is also a YouTube channel with free introductory videos and other noteworthy material.
Exam sample questions can help you check your knowledge and highlight areas requiring more study.
Remember, the best preparation for the exam is practical experience: AWS recommend 1+ years of hands-on experience with their technologies.
When you’re ready, go ahead and schedule an exam here.
Aligning OWASP Application Security Verification Standard and SABSA Architecture framework.
OWASP Application Security Verification Standard (Standard) is used at one of my clients to help develop and maintain secure applications. It has been used it as blueprint create a secure coding checklist specific to the organisation and applications used.
Below is an excerpt from the Standard related to the authentication verification requirements:
The Standard provides guidance on specific security requirements corresponding to the Physical layer of the SABSA architecture.
Organisations around the world are increasingly relying on third-party vendors to provide them with competitive advantage. Many companies in a race to optimise processes and reduce costs begin to outsource core functions. This leads to increased risk profile and new challenges of supplier oversight.
Dealing with third-parties has grown bigger than being just a procurement issue. Suppliers companies increasingly rely on, pose not only legal but also reputational risks that cannot be fully transferred. Security and privacy related incidents related to third-party providers are presenting new management challenges. Moreover, regulators are increasingly demanding the management of the third-party risk.
Suppliers, however, have their own challenges. Constant squeeze on costs from their clients reduces the profit margins making it increasingly difficult for vendors to prioritise security requirements implementation.
How do we make sure the suppliers we work with are trustworthy? How do we minimise the risk exposure from a potential incident? What level of assurance is required for a supplier?
These are the questions I’m going to answer in this blog.
Understanding business drivers and goals is essential for developing a third-party risk management approach. By analysing company’s corporate strategy I was able to derive multiple business attributes relevant to the shareholders. One of them stands out: Trusted. I’m going to disregard other attributes and focus on this one for the purposes of this case study. Not only it is important for the company to be trusted by its customers, but trustworthiness is also something I’m going to explore in this blog from the third-party relationship standpoint.
After a workshop with the CIO and IT managers in various business units, I’ve defined the following IT attributes supporting the main business attribute (Trusted): Transparent, Assured and Managed.
How does the security function support the wider IT objectives and corresponding attributes? After a number of workshops and analysing the security strategy document I’ve managed to create a number of security attributes. Below is a simplified example correlating to the business and IT attributes in scope:
Dealing with customers and managing relationships with them is one of the core activities of the company. As discussed above, being trusted by the customers is one of the main values of the organisation. IT department through the implementation of their technology strategy supported the business stakeholders in Sales and Marketing to outsource customer relationship management platform to a third party provider. A cloud-based solution has been chosen to fulfill this requirement.
A combination of attribute profiling, trust modelling and risk analysis is used to assess the degree of assurance required and compare third-party providers. Below is a recommended approach based on the attributes defined.
Security attributes mapping
Based on the internal security policy the following questionnaire has been developed to assess the supplier. Responses from the supplier have been omitted to preserve confidentiality. Below is a short excerpt from one of the sections of the questionnaire related to cloud services.
|Are terms of services and liabilities clearly defined in service agreements?||Governed|
|Are escrow arrangements in supplier contract agreement and cloud service agreements registered with procurement and documented in cloud service register.||Identified|
|Are physical security and environmental controls present in the data centre that contains company data?||Integrated|
|Are procedures for user authentication, authorization and access termination documented?||Access-Controlled|
|Has the Business Continuity Plan been reviewed and approved by the executive management?||Governed|
|How often is the Business Continuity Plans and Disaster Recovery Plans tested?||Available|
|Is there a specific Recovery Time Objective(s) (RTO) and Recovery Point Objective(s) (RPO)? If yes, specify the RTO and RPO for the company services.||Available|
|Are default settings customized to implement strong encryption for authentication and transmission?||Access-Controlled|
Attribute compliance is assessed based on the questionnaire answers, as every question is mapped to a specific attribute. Where a specific combination of an attribute corresponds to multiple questions, all answers are rated separately then an average rating for that attribute weight is calculated. Exceptions apply where certain specific questions are identified to have priority (higher level of impact on attribute compliance) over the other questions mapped to the same attribute. Expert judgement is applied to analyse such situations.
Attributes are evaluated with three main levels:
- High level of compliance with policy (Green),
- Medium level of compliance with policy (Amber),
- Low level of compliance with policy (Red)
I completed my SABSA Foundation training, passed the exam and earned the.SABSA Chartered Security Architect credential.
SABSA is a proven methodology for developing business-driven, risk and opportunity focused Security Architectures at both enterprise and solutions level that traceably support business objectives. It is also widely used for Information Assurance Architectures, Risk Management Frameworks, and to align and seamlessly integrate security and risk management into IT Architecture methods and frameworks.
SABSA is comprised of a series of integrated frameworks, models, methods and processes, used independently or as an holistic integrated enterprise solution, including:
- Business Requirements Engineering Framework (known as Attributes Profiling)
- Risk and Opportunity Management Framework
- Policy Architecture Framework
- Security Services-Oriented Architecture Framework
- Governance Framework
- Security Domain Framework
- Through-life Security Service Management & Performance Management Framework
Let’s start with the basics. How did you start your journey in information security?
Back in 1998 I graduated with a BSc in Computer Science and chose to focus on Object Oriented Analysis & Design and Java. In September 1999 I started contracting in the telecom industry in Netherlands. It was a unique, pre-dotcom-crash situation. A brand new multi-billion-dollar joint venture between two telecom groups – loads of money, starting from scratch with next to no infrastructure – really brilliant place for a relatively new graduate to come in to. A start-up with loads of money! While, officially regarded as a “Web Developer”, since they had no developer PCs, no servers, no DEV/TEST/Prod, no source-control, no standards, no policies, no DMZ; I ended up being involved in everything – and it was great! Set up policies, set up development standards, and specifying and ordering the PCs and software for the developers; specifying the servers for the website/database, and then being in meetings with the networking people to define what the firewall rules were going to be, and what we needed to do. Basically, doing everything!
A year later, I began a contract in Munich working as a secure Java developer using the new JAAS (Java Authentication and Authorisation Service) API in an Agile/Extreme programming team. So back in 2000 I was exposed to security and ever since I’ve kind of been in-and-out, either just doing application development or some other branch of security.
Then, in 2005 while I was working permanently with Accenture and I was exposed to identity management as a specific field –Thor Xellerate (later to become Oracle Identity Manager). Working on various client sites, I found identity management very interesting because it cut across every part of the business. Everybody in the business needs access to multiple, different systems, and the IDM provisions and de-provisions the users with the appropriate level of access, for all users.
Very interesting. What are you working at the moment?
In January, I was contacted by a cloud-based accountancy firm regarding a cyber-security voucher that the government was funding to encourage Small and Medium sized firms and Sole-traders to improve their cyber security stance.
It was one of the more enjoyable projects I’ve been involved in. Compared to working in a large faceless organisation, or government department, where you might disappear in amongst thousands of other small cogs, and your influences is small; here, you get to make an impact. When you are working in a smaller organisation of about 50 people or up to 200 people; your influence and impact is clear to see and is appreciated by the client. More over, since I’m communicating directly with the business leaders, the security serves the business needs instead of just an individual department’s needs.
Why do you think this is important? What is the main difference between working for a small company compared to a big one?
I believe you are going to understand their business better, so you can give genuinely relevant advice. You don’t need to worry about keeping your consultancy/employer or specific business-unit happy. You just need to focus on the business, and on giving them the best advice for them.
I hope to keep doing this for the foreseeable future, because it is easy to get bored of working in big companies. I mean, big organisations are nice because you get exposed to good technology, complex problems and huge projects etc., but as far as getting return for your work where you actually see results there and then; then you can’t beat the immediacy of an SME. You don’t need permission/sign-off from a dozen different stakeholders before you update that policy document. You change that policy or that you give them a piece of advice that has changed their focus to create a secure coding development platform; how to improve testing on that; you’ve given them access to resources they didn’t even know about, and you’ve given them new ideas and new perspectives.
And you’ve also shown them how they can actually improve themselves. So if they go for ISO 27001, that might be a differentiator between themselves and their competitors, and it’s also something that they can tell their customers: “We value your data privacy seriously, we have these standards in place, and we’re looking after you.”
When you work in security, you take a lot of things for granted. But then you go to some small or medium-sized companies, and they’ve been so focused on building their small business and delivering new functions, security is way back in their list of priorities. Now you get to raise that up and show them that it not only benefits them on the compliance side of things, but that the benefit also lies in their knowing where their data is, who has access to their data, they know when they have access to it. And you can put all sorts of different levels of controls onto things and give them a far greater peace of mind about how they are dealing with things internally to their company and how they are dealing with things with regards to their product. So delivering this cyber-security voucher to SMEs is something that I’m pursue with a lot more zeal at the moment, because I never knew about it before, and I know it can make a big difference to all of them. £5K is pretty meaningless to your average Fortune 500 company, but to an SME it is a pretty big deal.
What in your opinion is the main obstacle in implementing a similar approach in large corporations?
One of the problems with large corporations, and the same thing in government, is that each separate individual department has a budget. And they need to work to that budget, and they need to ensure that they are doing enough so that they get the same budget or more next year. And it gives a very narrow view to what they are doing. For me the best security (and IT investment in general) is when it is applied at the enterprise-level, across all of the various business units, and considers how we can make all of these people work well together. There is no point in having a really strong security in your finance department, when another department isn’t even talking to them, and they are doing similar work but on different platforms. On the one hand, you are wasting money, because they are duplicating work, they are duplicating data, they are duplicating the risks involved: in fact they are not even duplicating, they are making the risks much wider, because they may not be tracking where the data is going, and on another platform; its going all over the place.
[So if one department has Oracle DB, another is running Sybase and another small team has MS Access; a) You have the cost of the separate platforms; b) separate licensing for same task; c) you need to harden each platform separately; d) you need define a mechanism to share the data across the systems to maintain the integrity of the data; e) you need to support and patch separate systems etc. Conversely, the enterprise could have defined a single Database platform that all departments to use thus saving a world of pain.]
And while the ISO 27001 and various other standards out there will give you a kind of check-box compliance, “yes, we did this, we did this,” it doesn’t give you the kind of thing to say, “I feel comfortable about this.” Yes, you might feel comfortable about it if the legal department comes and questions you about it, but do you feel comfortable enough about it to be able to say that we have done a good job here, and we have delivered something to the client that actually works for them?
What about the security culture?
Yes, one of the things that I kept on stressing to one of my clients was: “you have a culture here that works for you. You have a very nice environment because everybody knows what’s going on here. If you are a developer, you know everybody in marketing, you know everybody in sales, and everybody knows you. And you have very free-flowing information going on, and it helps a great deal in how you operate. So when you are adding security controls, you don’t want to break what’s already working. You want to make sure it becomes better”.
Can security awareness training help to resolve this?
There is a problem with awareness training and educating users. If you are like me, I come from a technical background, you become very narrow-minded thinking: well I find technology very easy, why can’t you work it out? “Well, because I work in marketing!”
I don’t know anything about marketing so why should they know anything about technology?
There is a certain level of arrogance that we in technology developed about other people: in fact, there is a massive amount of arrogance, you come up with all kinds of deprecating or dismissive terms like “problem exists between keyboard and chair (PEBKAC)” or other phrases, just because they just don’t understand. Why don’t they understand? Because they are qualified for something completely different, something which you don’t understand.
So one should stop being so arrogant, step into their shoes, and understand them or try to find a way to translate what you do into terms that they will understand.
So what is the solution?
For me, I always go back to real world examples. Most people understand security from the real world. We are used to carrying five or six different keys for different things. But on the Internet, people only use one key; they only use one password. And they use it everywhere. So when it gets lost, people have access to everything that they own.
In the real world, I have a separate key for my car, a separate key for my home, a separate key for the main door vs. a separate key for my own apartment, and we are used to this kind of thing. But trying to explain to a user why it is that we use a password manager, we have to explain it to them in terms that they will actually understand, and actually take time for them to join the dots within their brain. “So that’s why I should have a different password. That’s why I should make my password really difficult.” Until they put two and two together, they are going to go for whatever is easiest.
So there are a lot of places where not only security people, but technology people in general need to learn to meet the end user halfway and make security transparent and ubiquitous: make security a layer that they don’t necessarily need to think about so much. But from our side, we need to make our code secure, we need to make our cloud system interactions secure, and we need to make our data policies and the implementation of our data policies secure.
Can you elaborate on security policies? Do you see any problems with them?
There’s no point in writing something in your policy that everyone is ignoring. There was a company a few years ago with the policy that nobody was allowed to use Microsoft Messenger. Everyone was using Microsoft Messenger! Your policy says this, and everyone is doing something different. So why is it written in your policy? Either train your people to not use it, and give them a valid, relevant, genuine alternative that they can use, or don’t put it in your policy.
And there are loads of things in the policy documents to please the auditors and to please the compliance team. But that is not how you do security. It in fact makes security worse because it gives the illusion to management that all these things are in place, when all the while the users are bypassing or ignoring it.
How security professionals can help the management in this case?
You need to give them the tools that help. If they are carrying client-data upon which they need to write reports, they need to do some data classification, state who should have access to it and how valuable things are. So if you have classified data, how should you encrypt it, how should you store it, how should you transfer it. So, for argument’s sake, buy a set of encrypted USB keys. If you know that people are working off of their laptops, get something like TrueCrypt or something else that encrypts their laptop, so that their laptop is encrypted if their laptop goes missing or something, you’re safe. Institute Two-Factor-Authentication. And, educate the user: you make sure they understand.
Are there any problems with implementation of such solutions?
Big corporations get these things, they throw loads of money at it, but they don’t look at it from the perspective of how does a business actually use this.
So one of the things which I was saying was that yes you can buy a really cool firewall and IPS system, but you can also do a simple hardening of your database, of your OS, of your application server, close down all of the open ports, close down all of the services that shouldn’t be on, and lets do some monitoring on some user behaviour, on how people are accessing your system. That will give you, for much cheaper, a whole load of control and peace of mind.
What the possible solution might be then?
From the technology and security side, you need to be aware of the business, and what are the drivers of this business, where do they make their money, where is the “data gold”, and what do they need to protect, and how they are going to protect that, and remain operational. You’ve got data which is very valuable to the company because it’s being used. If they can’t use that data, it’s worthless to them. So if you lock it down too much, or you prevent it from moving around to certain people, then you’re preventing the company from doing business. So until you actually understand that, you can’t put in the relevant controls to allow them to use their data and have a level of security.
You’re never going to be 100% secure, so trying to dream that you are going to be 100% secure is a waste of time, trying to do it by way of fear and scaring your client into doing things is a completely wrong way of doing things, because when you are in a state of fear, your judgment is so far off the mark, that it’s ridiculous. Whereas in the case of “I understand what I’m doing over here. Yes, there are some dangers in this. But we understand it.“
Can you give an example?
It is all about risk management – don’t be afraid of them; simply understand them and manage accordingly.
I’m a snowboarder, and last winter I did an avalanche skills training certification course. The way they manage risk is very similar to how we in security do many things (In many respects they are better because lives depend on it). They have to look at a lot of different things that can trigger an avalanche –current weather conditions, weather over the preceding weeks, terrain, different types of snow; which places you are in danger of being in an avalanche, and there are various trigger points and safety concerns (yes, it gets complicated). You don’t live in fear of avalanches because you saw something in some crappy disaster movie. Instead you live in awareness of it and manage your safety. It’s called awareness training, as opposed to a “you’ll magically be safe from an avalanche by doing this.” It’s a case of saying: right, these are different factors that can trigger an avalanche and these are different things that can make you safer from an avalanche.
So if you have had a lot of snowfall in the preceding days followed by a rapid thaw, then it is very likely that some areas on the mountains will have avalanches. So under those circumstances, you don’t go out into very steep slopes, you stay on the slopes that are shallower, or in the treeline. Yes, you may not have as much fun, but you live to play another day.
Before you go out, there are a few things that you are supposed to do. You’re supposed to notify people that this the zone that we are going to, you define a leader of the group, you take all the various precautions that you have all the avalanche transceivers, probes and shovels, and all these kind of things so that, if the worst happens, you are prepared to dig someone out, and that kind of stuff.
Are there any issues applying the same principles to security?
When you go to have your tyres changed, you don’t need to tell the mechanic to make sure to pump up the tires to the correct pressure. They do it automatically. But for us in IT, we need to stipulate this bunch of standard documents and requirements, and we have this non-functional sets that put these standards in place, “you will make sure that you are using this framework” to prevent SQLi attacks. People should be doing this automatically in our industry (it should be part of our quality process), but we don’t do it.
And there is a lot on our side to blame, because we don’t communicate properly, we don’t talk to the right people. And we also have a tendency to think: I told you once, how come you haven’t changed it?
We want it instantly, or at the latest, tomorrow. No, it’s going to take them time to learn, it’s going to take them time to step up their game to the correct level. And you need to be appreciative of this.
What is your approach?
There’s no one magic bullet that will solve this problem, since it is spread across so many systems and every business is different.
For a previous client, following initial meetings, I setup multiple security roadmaps for them in the three areas that we chose to focus on: business continuity planning; software development and data privacy.
How was this to be achieved? What steps must we take in the next week, month, quarter and where do we expect to be in six months from now. The steps we take must be measureable to some degree. This allowed us to apply a maturity model to it.
It involved some technology, some education, and a lot of communication across business domains and teams to ensure we were serving the business. It also involved the flexibility to acknowledge what isn’t working and change accordingly.
So we have a way of setting these things up so that we can track how well are we doing and where we are, and then you’ve got the ways for them, for the technical team to give feedback back to management, to say that “we’ve added this, and this has given us this additional benefit”.
Thank you Yousef. A few final words of wisdom, please.
You need to be honest with your customer. Sometimes they are not going to listen and you are going to have to do what they want you to do, and that’s part of the business. But you need to understand what the business is, and not just the department that you are being called into. You need to explore what is going on at an enterprise level.