AWS security fundamentals: IAM

IAM

Here I am going to build on my previous blog of inventorying AWS accounts and talk about identity and access management. By now you have probably realised that your organisation, depending on its size, has more accounts with a lot of associated resources than you initially thought. The way users are created and access is managed in these accounts has a direct impact on the overall security of your infrastructure.

What accounts should your company have? Well it really depends on the nature of your organisation but I tend to see the following pattern for software development driven companies:

1. Organisation root. Your organisation root account should be used to create other accounts (and some other limited amount of operations) and otherwise shouldn’t be touched. Secure the credentials and leave it alone. It should not have any resources associated with it.

2. Identity. Not strictly necessary to have a separate account for this but isn’t it great to be able to manage all your users in a single account?

3. Operations. This account should be used for log collection and analysis. Your security team will be happy.

4, 5 and 6. A separate account for your development, staging and production environments. It’s a good idea to separate them for the ease of managing permissions and pleasing auditors.

Users and services that are managed within an AWS account, should only get access to what they need.

Security specialists are spending a great deal of their time reviewing firewall rules when working on their on-premise infrastructure to ensure they are not too permissive. When we move to the cloud, these rules look somewhat different but their importance has only increased.

To demonstrate the relationship between accounts, users, groups, roles and permissions, let’s walk through an example scenario of a developer in your company requiring read only access to the staging environment.

No automation or anything even remotely advanced is going to be discussed here as we are just covering the basics in this blog. It is no less important, however, to get these right. The principles discussed here will lay the foundation for more advanced concepts. Again, the terminology here is specific to AWS but overarching principles can be applied to any cloud environment.

To start with this scenario, let’s create a custom role CompanyReadOnly and attach an AWS managed ReadOnlyAccess policy in the Permissions tab.

Role Policies
CompanyReadOnly ReadOnlyAccess

This role allows a trusted entity (an account in this case) to access this account. When you access this account you will get the permissions defined in the policy.

Let’s say we have an account where all users are managed (the Identity account in point 2 in the list above). In this account, create a custom policy CompanyAssumeRoleStagingReadOnly allowing assuming the right role, where 123456789012 is Staging account ID which is the trusted entity for the Identity account:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::123456789012:role/CompanyReadOnly"
        }
    ]
}

Now let’s create a custom StagingReadOnly group and attach the above policy in the Permission tab.

Group Permissions
StagingReadOnly CompanyAssumeRoleStagingReadOnly

Finally add a user to that group:

User Group Permissions
Developer StagingReadOnly CompanyAssumeRoleStagingReadOnly

In this group additional permissions can be added, e.g. AWS managed enforce-mfa policy for mandatory multi-factor authentication.

Of course, granular policies specifying access to particular services rather than blanket ReadOnly is preferred. Remember the aim here is to demonstrate IAM fundamental principles rather than recommend specific approaches you should use. The policies will depend on the AWS resources your organisation actually uses.


Learn software engineering

Python_logo_and_wordmark.svg

I’ve recently decided to brush up on my programming skills with one of the courses on Udemy. Despite completing a degree in Computer Science back in the day, my recent focus has been away from software development and a lot has changed since I graduated.

At university I studied mathematics and algorithms but actual programming was performed on archaic languages – such as Pascal for high-level and Assembly for low-level programming.

Although they provide a solid foundation, I was looking for something more practical and because of this I ended up taking up Python because of its versatility. Python is not only widely used, but can also be applied to a variety of projects, including data analysis and machine learning.

The course has been very good and Jupyter notebooks with extensive comments and exercises are available for free on GitHub.

You can start applying it in practice straight away or just have some fun with your own pet projects.

If you’re an experienced developer or just want to have some extra practice, I found the below brain teasers quite entertaining:

On the other hand, if you are just starting up and would like some more grounding in computer science, check out Harvard University’s CS50’s Introduction to Computer Science. It’s completely free, online and self-paced. It starts with some basic principles and lets you put them into practice straight away through Scratch, a graphical programming language developed by MIT.  You then go on to learn more advanced concepts and apply them using C, Python, JavaScript and more.

The course also has a great community, so I highly recommend checking it out.


Startup security

14188692143_8ed6740a1d_z

In the past year I had a pleasure working with a number of startups on improving their security posture. I would like to share some common pain points here and what to do about them.

Advising startups on security is not easy, as it tends to be a ‘wicked’ problem for a cash-strapped company – we often don’t want to spend money on security but can’t afford not to because of the potential devastating impact of security breaches. Business models of some of them depend on customer trust and the entire value of a company can be wiped out in a single incident.

On a plus side, security can actually increase the value of a startup through elevating trust and amplifying the brand message, which in turn leads to happier customers. It can also increase company valuation through demonstrating a mature attitude towards security and governance, which is especially useful in fundraising and acquisition scenarios.

Security is there to support the business, so start with understanding the product who uses it.  Creating personas is quite a useful tool when trying to understand your customers. The same approach can be applied to security. Think through the threat model – who’s after the company and why? At what stage of a customer journey are we likely to get exposed?

Are we trying to protect our intellectual property from competitors or sensitive customer data from organised crime? Develop a prioritised plan and risk management approach to fit the answers. You can’t secure everything – focus on what’s truly important.

A risk based approach is key. Remember that the company is still relatively small and you need to be realistic what threats we are trying to protect against. Blindly picking your favourite NIST Cybersecurity Framework and applying all the controls might prove counterproductive.

Yes, the challenges are different compared to securing a large enterprise, but there some upsides too. In a startup, more often than not, you’re in a privileged position to build in security and privacy by design and deal with much less technical debt. You can embed yourself in the product development and engineering from day one. This will save time and effort trying to retrofit security later – the unfortunate reality of many large corporations.

Be wary, however, of imposing too much security on the business. At the end of the day, the company is here to innovate, albeit securely. Your aim should be to educate the people in the company about security risks and help them make the right decisions. Communicate often, showing that security is not only important to keep the company afloat but that it can also be an enabler. Changing behaviours around security will create a positive security culture and protect the business value.

How do you apply this in practice? Let’s say we established that we need to guard the company’s reputation, customer data and intellectual property all the while avoiding data breaches and regulatory fines. What should we focus on when it comes to countermeasures?

I recommend an approach that combines process and technology and focuses on three main areas: your product, your people and your platform.

  1. Product

Think of your product and your website as a front of your physical store. Thant’s what customers see and interact with. It generates sales, so protecting it is often your top priority. Make sure your developers are aware of OWASP vulnerabilities and secure coding practices. Do it from the start, hire a DevOps security expert if you must. Pentest your product regularly. Perform code reviews, use automated code analysis tools. Make sure you thought through DDoS attack prevention. Look into Web Application Firewalls and encryption. API security is the name of the game here. Monitor your APIs for abuse and unusual activity. Harden them, think though authentication.

  1. People

I talked about building security culture above, but in a startup you go beyond raising awareness of security risks. You develop processes around reporting incidents, documenting your assets, defining standard builds and encryption mechanisms for endpoints, thinking through 2FA and password managers, locking down admin accounts, securing colleagues’ laptops and phones through mobile device management solutions and generally do anything else that will help people do their job better and more securely.

  1. Platform

Some years ago I would’ve talked about network perimeter, firewalls and DMZs here. Today it’s all about the cloud. Know your shared responsibility model. Check out good practices of your cloud service provider. Main areas to consider here are: data governance, logging and monitoring, identity and access management, disaster recovery and business continuity. Separate your development and production environments. Resist the temptation to use sensitive (including customer) data in your test systems, minimise it as much as possible. Architect it well from the beginning and it will save you precious time and money down the road.

Every section above deserves its own blog and I have deliberately kept it high-level. The intention here is to provide a framework for you to think through the challenges most startups I encountered face today.

If the majority of your experience comes from the corporate environment, there are certainly skills you can leverage in the startup world too but be mindful of variances. The risks these companies face are different which leads to the need for a different response. Startups are known to be flexible, nimble and agile, so you should be too.

Image by Ryan Brooks.


Securing JSON Web Tokens

snip20190118_5

JSON Web Tokens (JWTs) are quickly becoming a popular way to implement information exchange and authorisation in single sign-on scenarios.

As with many things, this technology can be either quite secure or very insecure at the same time and a lot is dependent on the implementation. This opens a number of possibilities for attackers to exploit vulnerabilities if this standard is poorly implemented or outdated libraries are sued.

Here are some of the possible attack scenarios:

  • A attackers can modify the token and hashing algorithm to indicate, through the ‘none’ keyword, that the integrity of the token has already been verified, fooling the server into accepting it as a valid token
  • Attackers can change the algorithm from ‘RS256’ to ‘HS256’ and use the public key to generate a HMAC signature for the token, as server trusts the data inside the header of a JWT and doesn’t validate the algorithm it used to issue a token. The server will now treat this token as one generated with ‘HS256’ algorithm and use its public key to decode and verify it
  • JWTs signed with HS256 algorithm could be susceptible to private key disclosure when weak keys are used. Attackers can conduct offline brute-force or dictionary attacks against the token, since a client does not need to interact with the server to check the validity of the private key after a token has been issued by the server
  • Sensitive information (e.g. internal IP addresses) can be revealed, as all the information inside the JWT payload is stored in plain text

I recommend the following steps to address the concerns above:

  • Reject tokens set with ‘none’ algorithm when a private key was used to issue them
  • Use appropriate key length (e.g. 256 bit) to protect against brute force attacks
  • Adjust the JWT token validation time depending on required security level (e.g. from few minutes up to an hour). For extra security, consider using reference tokens if there’s a need to be able to revoke/invalidate them
  • Use HTTPS/SSL to ensure JWTs are encrypted during client-server communication, reducing the risk of the man-in-the-middle attack
  • Overall, follow the best practices for implementing them, only use up-to-date and secure libraries and choose the right algorithm for requirements

OWASP have more detailed recommendations with Java code samples alongside other noteworthy material for common vulnerabilities and secure coding practices, so I encourage you to check it out if you need more information.


Amsterdam

This is one of these blog posts with no content. I just really wanted to share some pics from one of the coolest cities I had a privilege to live and work in for the past few months.


Using SABSA for application security

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:

OWASP

The Standard provides guidance on specific security requirements corresponding to the Physical layer of the SABSA architecture.

SABSA views

Read the rest of this entry »


Biometric authentication

If you want to learn more about biometric authentication, the best place to start is FIDO Alliance. Regardless of where you stand when it comes to passwords (are they obsolete and must be eliminated?), their standards and specifications can be useful.

The ecosystem enables enterprises and service providers to deploy strong authentication solutions that reduce reliance on passwords and protect against phishing, man-in-the-middle and replay attacks using stolen passwords.


Information Security E-Learning Part 2

ID-100188595

In my previous post I discussed free online courses in information security. Here  I would like to share a few more resources.

Read the rest of this entry »


Konrads Smelkovs: Very few insiders develop overnight

Interview with Konrads Smelkovs – Incident Response

Konrads

Could you please tell us a little bit about your background?

I work at KPMG as a manager, and I started working with security when I was around thirteen years old. I used to go to my mother’s work, because there was nobody to look after me. There used to be an admin there who used to run early versions of Linux, which I found to be rather exciting. I begged him to give me an account on his Linux box, but I didn’t know much about that, so I started searching for information in Altavista. The only things you could find there was how to hack into Unix, and there were no books at the time I could buy. I downloaded some scripts off the internet and started running them. Some university then complained that my scripts were hacking them, though I didn’t really understand much of what I was doing. So my account got suspended for about half a year, but I got hooked and found it rather interesting and exciting, and developed an aspiration in this direction. I then did all sorts of jobs, but I wanted a job in this field. So I saw an add in the newspaper and applied for a job at KPMG back in Latvia, 6 or 7 years ago. I was asked what it is I could do, and I explained to them the sort of things I had done in terms of programming: “a little bit of this, a little bit of that…”, I did some reading about security before the interview, and they then asked me if I could do penetration testing. I had a vague idea of what it entailed, because I understood web applications quite well. So I said, “yeah, sure. I can go ahead and do that because I understand these things quite well.”

What are you working on at the moment?

In the past I used to focus mainly on break-ins. Now people resort to me for advice on how to detect on-going intrusions, which takes up a large portion of my time at the moment, but more at a senior level. I do threat modelling for a corporation. I have to know how to break-in in order to give them reasonable advice, but it’s mainly in the form of PowerPoint presentations and meetings.

When you develop threat models for corporations, how do you factor in insider threats as well as the human aspect of security?

I believe the industry oscillates from one extreme to the other. People spoke a lot about “risk” but they understood very little about what this risk entailed. They then spoke about IT risks, but it was more of a blank message. Then it all became very entangled, and there was talk about vulnerability thinking: “you have to patch everything.” But then people realised that there is no way to patch everything, and then started talking about defence strategies, which pretty much everybody misunderstands, and so they started ignoring vulnerabilities. This especially happened because we all had firewalls, but we know that those don’t help either. So what we are trying to do here is to spread common sense in one go. When we talk about threat models, we have to talk about who is attacking, what they are after, and how they will do it. So the “who” will obviously have a lot of different industry properties, why they are doing it, what their restrictions and their actions are and so on. Despite the popular belief in the press, in The Financial Times, CNN, and so on, everybody talks about the APT, these amazing hackers hacking everything. They don’t realise that the day-to-day reality is quite different. There are two main things people are concerned about. One of them is insider threats, because insiders have legitimate access, and just want to elevate that access by copying or destroying information. The second is malware, which is such a prevalent thing. Most malware is uploaded by criminals who are not specifically after you, but are after some of your resources: you are not special to them. There are very few industries where there is nation-state hacking or where competitive hacking is current. So when we talk about threat models, we mainly talk about insider threats within specific business units and how they work. This is what I think people are most afraid of: the exploitation of trust.

How do you normally advice executives in organisations about proper information security? Do you focus on building a proper security culture, on awareness training, technological/architectural means, or what do you consider is the most important thing they should keep in mind?

We need to implement lots of things. I believe that a lot of the information security awareness training is misguided. It is not about teaching people how to recognise phishing or these sort of things. It is about explaining to them why security is important and how they play a part in it.

Very few insiders develop overnight and I believe that there is a pattern, and even then, insiders are rare. Most of the time you have admins who are trying to make themselves important, or, who out of vengeance, try to destroy things. So whenever you have destruction of information, you have to look at what kind of privileged access there is. Sometimes people copy things in bulk when they leave the company, to distribute it to the company’s competitors.

So lets say you develop a threat model and present it to the company, who’s executives accepted and use to develop a policy which they then implement and enforce. Sometimes, these policies my clash with the end-users’ performance and affect the way business within the company is done. Sometimes they might resist new controls because privileges get taken away. How would you factor in this human aspect, in order to avoid this unwanted result?

Many companies impose new restrictions on their employees without analysing the unwanted result it may lead to. So for example, if companies don’t facilitate a method for sharing large files, the employees might resort to Dropbox which could represent a potential threat. Smart companies learn that it is important to offer alternatives to the privileges they remove from their employees.

How do you go by identifying what the users need?

They will often tell you what it is they need and they might even have a solution in mind. It’s really about offering their solutions securely. Rarely is the case when you have to tell them that what they want is very stupid and that they simply should not do it.

Finally, apart from sharp technical skills, what other skills would you say security professionals need in order to qualify for a job?

You have to know the difference between imposing security and learning how to make others collaborate with security. Having good interpersonal skills is very important: you need to know how to convince people to change their behaviour.

Thank you Konrads.


Yousef Syed: Most people understand security from the real world

Interview with Yousef Syed – Enterprise Security Architect at Bayvision Limited

Syed

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.