I’ve had a chance to discuss current challenges in and approaches for building a security culture during an interview with IT Governance Publishing about my book. I also talked about why I do what I do. I hope you enjoy it.
How to manage vulnerabilities in your open source packages. Part 2: Integrating Snyk in your CI/CD pipeline
We learnt how to detect vulnerable packages in your projects using Snyk in the previous blog. Here, in the true DevSecOps fashion, I would like outline how to integrate this tool in your CI/CD pipeline.
Although the approach described in the previous blog has its merits, it lacks proactivity, which means you might end up introducing outdated packages in your codebase. To address this limitation, I’m going to describe how to make Snyk checks part of your deployment workflow. I’ll be using CircleCI here as an example, but the principles can be applied using any CI tool.
A step-by-step guidance on configuring the integration is available on both the Snyk and CircleCI websites. In the nutshell, it’s just about adding the Snyk Orb and API to CircleCI.
After the initial set-up, an additional test will be added to your CircleCI workflow.
If vulnerabilities are identified, you can set CircleCI to either fail the build to prevent outdated libraries to be introduced or let the build complete and flag.
Both methods have their pros and cons and will depend on the nature of your environment and risk appetite. It’s tempting to force the build fail to prevent more vulnerable dependencies being introduced but I suggest doing so only after checking with your developers and remediating existing issues in your repositories using the method described in the previous blog.
Snyk’s free version allows you only a limited number of scans per month, so you need to also weigh costs agains benefits when deploying this tool in your development, staging and production environments.
This approach will allow you to automate security tests in a developer-friendly fashion and hopefully bring development and security teams closer together, so the DevSecOps can be practiced.
How to manage vulnerabilities in your open source packages. Part 1: Using Snyk
We rely on open source libraries when we write code because it saves a lot of time (modern applications rely on hundreds of them), but these dependencies can also introduce vulnerabilities that are tricky to manage and easy to exploit by attackers.
One way of addressing this challenge is to check the open source packages you use for known vulnerabilities.
In this blog I would like to discuss how to do this using an open source tool called Snyk.
The first thing you want to do after creating an account is to integrate Snyk with your development environment. It supports a fair amount of systems, but here I would like to talk about GitHub as an example. The process of getting the rest of the integrations are pretty similar.
Snyk’s browser version has an intuitive interface and all you need to do is go to the Integrations tab, select GitHub and follow the instructions.
After granting the necessary permissions and selecting the code repositories you want tested (don’t forget the private ones too), they will be immediately scanned.
You will be able to see the results in the Projects tab with issues conveniently ordered by severity so you can easily prioritise what to tackle first. You can also see the dependency tree there which can be quite handy.
A detailed description of the vulnerability and some recommendations on how to remediate it are also provided.
Most vulnerabilities can be fixed through either an upgrade or a patch and that’s what you should really do, or ask someone (perhaps by creating a ticket) if you don’t own the codebase. Make sure you test it first though as you don’t want the update to break your application.
Some fancy reporting (and checking license compliance) is only available in the paid plan but the basic version does a decent job too.
You can set up periodic tests with desired frequency (daily or weekly) which technically counts as continuous monitoring but it’s only the second best option compared to performing tests in your deployment pipeline. Integrating Snyk in your CI/CD workflow allows to prevent issues in your code before it even gets deployed. This is especially useful in organisations where code gets deployed multiple times a day with new (potentially vulnerable) libraries being introduced. And that’s something we are going to discuss in my next blog.
AWS security fundamentals: 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.
How to inventory your AWS assets
Securing your cloud infrastructure starts with establishing visibility of your assets. I’ll be using Amazon Web Services (AWS) as an example here but principles discussed in this blog can be applied to any IaaS provider.
Speaking about securing your AWS environment specifically, a good place to start is the AWS Security Maturity Roadmap by Scott Piper. He suggests identifying all AWS accounts in your organisation as a first step in your cloud security programme.
Following Scott’s guidance, it’s a good idea to check in with your DevOps team and/or Finance to establish what accounts are being used in your company. Capture this information in a spreadsheet, documenting account name, ID, description and an owner at a minimum. You can expand on this in the future to track compliance with baseline requirements (e.g. enabling CloudTrail logs).
Once we have a comprehensive view of the accounts used in the organisation, we need to find out what resources these accounts use and how they are configured. The simplest way is perhaps to use the AWS Config service. But if you want more detail (and service coverage), you can get metadata about the accounts using CloudMapper’s collect command. CloudMapper is a great open source tool and can do much more than that. It deserves a separate blog, but for now just check out setup instructions on its GitHub page and Scott’s detailed instructions on using the collect command.
The CloudMapper report will reveal the resources you use in all the regions (the image at the top of this blog is from the demo data). This can be useful in scenarios where employees in your company might test out new services and forget to switch them off or nobody knows what these services are used for to begin with. In either case, the company ends up paying for these, so it makes economic sense to investigate, and disabling them will also reduce the attack surface.
In addition to that, the report includes a section on security findings and will alert of potential misconfigurations on the account. It also provides recommendations on how to address them. Below is an example report based on the demo data.
As we are just establishing the view of our assets in AWS at this stage, we are not going to discuss remediation activities in this blog. We will, however, use this report to understand how much work is ahead of us and prioritise accordingly.
Of course, it is always a good idea to tackle high criticality issues like publicly exposed S3 buckets with sensitive information but don’t get discouraged by a potentially large number of security findings. Instead, focus on strategic improvements that will prevent these issues from happening in the future.
To lay the foundation for a security improvements programme at this point, I suggest adding all the identified accounts to an AWS Organisation if you haven’t already. This will simplify account management and billing and allow you to apply organisation-wide service control policies.
Security product management
In one of my previous blogs I wrote about building a security startup. Here I would like to elaborate on the product management aspect of a venture.
There are many businesses springing up in the cybersecurity space at the moment. A lot of them are developed by great technologists yet still struggle. The market conditions might be right and the product itself can be secure but it often fails to get traction.
When I’m asked why this might be and what to do about it, my immediate response is to dive deeper and understand the product management function.
In truth, it’s not enough to have a technically flawless solution, it has to align with what your customers want. Moreover, the bar in new product adoption is high. As Nir Eyal famously pointed out in his book Hooked, “for new entrants to stand a chance, they can’t just be better, they must be nine times better … because old habits die hard and new products or services need to offer dramatic improvements to shake users out of old routines. Products that require a high degree of behaviour change are doomed to fail even if the benefits of using the new product are clear and substantial.”
Thankfully, it’s not all doom and gloom – there are things you can do to overcome this challenge.
Depending on the stage of your venture, the most important question to answer is: are people using your product? If not, get to the point where customers are using your product as fast as you can. Then talk to them and learn from them. Find out what problem they are trying to solve.
Provide that solution and measure what matters (revenue, returning usage, renewal rate) and build measurement targets and mechanisms into your specifications.
Disciplined product management is there to bridge the gap between business (sales and marketing) and technology teams. As a product manager, you should support these teams with market analysis, planning, prioritisation, design and measurement based on customer feedback.
Knowledge of the customer and their needs will help define your strategic position and overarching guiding principles to support decision-making in the company.
That strategy in turn should be supported by tactical steps to achieve the vision. We are now beginning to shape actual work deliverables and help the technology teams prioritise them in your development sprints.
Principles described here are applicable in any type of organisation, it doesn’t have to be security specific. The industry you are in matters less than the company culture.
People often focus on tools when talking about product management or adopting agile development. The reality is that it’s often about the culture of collaboration. Break the silos, make sure customer feedback is guiding the development and don’t lose sight of the strategy. Your customers will love it, I promise.
GITEX Technology Week in Dubai
I travelled to Dubai to attend the GITEX conference this year. The scope and scale of this technology event is vast. It covers all things tech with a focus on innovation, including artificial intelligence, 5G, smart cities, future mobility and much more.
It was interesting to attend talks and participate in workshops, as well as just walk the floor to better understand current technology trends.
Of course, there was also time to explore Dubai and enjoy the many things this city has to offer.
How to respond to a security incident
In this blog I would like to outline a process of responding to a security incident, including a breach of personal data. It is intended to be high-level in nature to allow for adaptation to different types of incidents and specific needs of your organisation.
There are many definitions of a security incident out there. I prefer this one: a security incident is an attempted or successful unauthorised access, use, theft, disclosure, modification or destruction of information, or interference with or misuse of information processing infrastructure, applications and data. A personal data breach is one of the types of a security incident which occurs when personal information is subject to loss or unauthorised access, use, disclosure, copying or modification.
Cyber security in divestments
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.
Image by Jason Kuffer.
What can a US Army General teach us about security?
General Douglas MacMarthur said “never give an order that can’t be obeyed”. This is sound advice, as doing so can diminish the commander’s authority. If people want to do what you are asking them to do, but can’t, they would doubt your judgement in the future.
Despite the fact that most of us operate in commercial organisations rather than the US Army, there are some lessons to be learned from this.
Security professionals don’t need to rally their troops and rarely operate in command-and-control environments. Their role has largely shifted to the one of an advisor to the business when it comes to managing cyber risk. Yet all too often advice they give is misguided. In an effort to protect the business they sometimes fail to grasp the wider context in which it operates. More importantly, they rarely consider their colleagues who will have to follow their guidance.
Angela Sasse gives a brilliant example of this when she talks about phishing. Security professionals expect people to be able to identify a phishing email in order to keep the company secure. Through numerous awareness sessions they tell them how dangerous it is to click on a link in a phishing email.
Although it makes sense to some extent, it’s not helpful to expect people to be able to recognise a phishing email 100% of the times. In fact, a lot of information security professionals might struggle to make that distinction themselves, especially when it comes to more sophisticated cases of spear phishing. So how can we expect people who are not information security specialists to measure up?
To make matters worse, most of modern enterprises depend on email with links to be productive. It is considered normal and part of business as usual to receive an email and click on the link in it. I heard of a scenario where a company hired an external agency and paid good money for surveying their employees. Despite advance warnings, the level of engagement with this survey was reduced as people were reporting these external emails as “phishing attempts”. The communications team was not pleased and that certainly didn’t help establish the productive relationship with the security team.
The bottom line is that if your defences depend on people not clicking on links, you can do better than that. The aim is not to punish people when they make a mistake, but to build trust. The security team should therefore be there to support people and recognise their challenges rather than police them.
After all, when someone does eventually click on a malicious link, it’s much better if they pick up the phone to the security team and admit their mistake rather than hope it doesn’t get noticed. Not only does this speed-up incident response, it fosters the role of the security professional as a business enabler, rather than a commander who keeps giving orders that can’t be obeyed.
Cyber Security Leadership 