Using abstractions to think about risks is a useful technique to identify the ways an attacker could compromise a system.
There are various approaches to perform threat modelling but at the core, it’s about understanding what we are building, what can go wrong with it and what we should do about it.
Here is a good video by SAFECode introducing the concept:
I had a lot of fun participating in a panel discussion with fellow CISOs exploring the link between cyber security and business strategy. It’s a subject that is very close to my heart and I don’t think it gets enough attention.
In the course of the debate we covered a number of topics, ranging from leveraging KPIs and metrics to aligning with the Board’s risk appetite. We didn’t always agree on everything but I believe that made the conversation more interesting.
As an added bonus, my book The Psychology of Information Security was highlighted as an example of things to consider while tackling this challenge and to improve communication.
You can watch the recording on BrightTalk.
Chief Information Security Officer Workshop is a collection of on-demand videos and slide decks from Microsoft aimed to help CISOs defend a hybrid enterprise (that now includes cloud platforms) from increasingly sophisticated attacks.
I had a chance to contribute to a free eBook by Cisco on adapting to the challenges presented by the Covid-19 pandemic. Check it out for advice on securing your remote workforce, improving security culture, adjusting your processes and more.
Oil & Gas has always been an industry affected by a wide range of geopolitical, economical and technological factors. The energy transition is one of the more recent macro trends impacting every player in the sector.
Companies are adjusting their business models and reorganising their organisational structures to prepare for the shift to renewable energy. They are becoming more integrated, focusing on consumers’ broader energy needs all the while reducing carbon emissions and addressing sustainability concerns.
To enable this, the missing capabilities get acquired and unwanted assets get divested. Cyber security has a part to play during divestments. preventing business disruption and data leaks during handover. In acquisition scenarios, supporting due diligence and secure integration becomes a focus.
Digital transformation is also high on many boards’ agenda. While cyber security experts are still grappling with the convergence of Information Technology (IT) and Operational Technology (OT) domains, new solutions are being tried out: drones are monitoring for environmental issues, data is being collected from IoT sensors and crunched in the Cloud with help of machine learning. These are deployed alongside existing legacy systems in the geographically distributed infrastructure, adding complexity and increasing attack surface.
It’s hard, it seems, to still get the basics right. Asset control, vulnerability and patch management, network segregation, supply chain risks and poor governance are the problems still waiting to be solved.
The price for neglecting security can be high: devastating ransomware crippling global operations, industrial espionage and even a potential loss of human life as demonstrated by recent cyberattacks.
It’s not all doom and gloom, however. There are many things to be hopeful for. Oil & Gas is an industry with a strong safety culture. The same processes are often applied in both an office and an oil rig. People will actually intervene and tell you off if you are not holding the handrail or carrying a cup of coffee without a lid.
To be effective, cyber security needs to build on and plug into these safety protocols. In traditional IT environments, confidentiality is often prioritised. Here, safety and availability are critical. Changing the mindset, and adopting safety-related principles (like ALARP: as low as resonantly practicable) and methods (like Bowtie to visualise cause and consequence relationships in incident scenarios) when managing risk is a step in the right direction.
Photo by Jonathan Cutrer.
In the past year I had the opportunity to help a tech startup shape its culture and make security a brand differentiator. As the Head of Information Security, I was responsible for driving the resilience, governance and compliance agenda, adjusting to the needs of a dynamic and growing business.
Thank you for visiting my website. I’m often asked how I started in the field and what I’m up to now. I wrote a short blog outlining my career progression.
I’ve been asked to join PigeonLine as a Board Advisor for cyber security. I’m excited to be able to contribute to the success of this promising startup.
PigeonLine is a fast growing AI development and consulting company that builds tools to solve common enterprise problems. Their customers include the UAE Prime Ministers Office, the Bank of Canada, the London School of Economics, among others.
Building accessible AI tools to empower people should go hand-in-hand with protecting their privacy and preserving the security of their information.
I like the company’s user-centric approach and the fact that data privacy is one of their core values. I’m thrilled to be part of their journey to push the boundaries of human-machine interaction to solve common decision-making problems for enterprises and governments.
There are several ways to implement threat detection in AWS but by far the easiest (and perhaps cheapest) set up is to use Amazon’s native GuardDuty. It detects root user logins, policy changes, compromised keys, instances, users and more. As an added benefit, Amazon keep adding new rules as they continue evolving the service.
To detect threats in your AWS environment, GuardDuty ingests CloudTrail, VPC FlowLogs and VPC DNS logs. You don’t need to configure these separately for GuardDuty to be able to access them, simplifying the set up. The price of the service depends on the number of events analysed but it comes with a free 30-day trial which allows you to understand the scope, utility and potential costs.
It’s a regional service, so it should be enabled in all regions, even the ones you currently don’t have any resources. You might start using new regions in the future and, perhaps more importantly, the attackers might do it on your behalf. It doesn’t cost extra in the region with no activity, so there is really no excuse to switch it on everywhere.
To streamline the management, I recommend following the AWS guidance on channelling the findings to a single account, where they can be analysed by the security operations team.
It requires establishing master-member relationship between accounts, where the master account will be the one monitored by the security operations team. You will then need to enable GuardDuty in every member account and accept the invite from the master.
You don’t have to rely on the AWS console to access GuardDuty findings, as they can be streamed using CloudWatch Events and Kinesis to centralise the analysis. You can also write custom rules specific to your environment and mute existing ones customising the implementation. These, however, require a bit more practice, so I will cover them in future blogs.
Committing passwords, SSH keys and API keys to your code repositories is quite common. This doesn’t make it less dangerous. Yes, if you are ‘moving fast and breaking things’, it is sometimes easier to take shortcuts to simplify development and testing. But these broken things will eventually have to be fixed, as security of your product and perhaps even company, is at risk. Fixing things later in the development cycle is likely be more complicated and costly.
I’m not trying to scaremonger, there are already plenty of news articles about data breaches wiping out value for companies. My point is merely about the fact that it is much easier to address things early in the development, rather than waiting for a pentest or, worse still, a malicious attacker to discover these vulnerabilities.
Disciplined engineering and teaching your staff secure software development are certainly great ways to tackle this. There has to, however, be a fallback mechanism to detect (and prevent) mistakes. Thankfully, there are a number of open-source tools that can help you with that:
You will have to assess your own environment to pick the right tool that suits your organisation best.
If you read my previous blogs on integrating application testing and detecting vulnerable dependencies, you know I’m a big fan of embedding such tests in your Continuous Integration and Continuous Deployment (CI/CD) pipeline. This provides instant feedback to your development team and minimises the window between discovering and fixing a vulnerability. If done right, the weakness (a secret in the code repository in this case) will not even reach the production environment, as it will be caught before the code is committed. An example is on the screenshot at the top of the page.
For this reason (and a few others), the tool that I particularly like is detect-secrets, developed in Python and kindly open-sourced by Yelp. They describe the reasons for building it and explain the architecture in their blog. It’s lightweight, language agnostic and integrates well in the development workflow. It relies on pre-commit hooks and will not scan the whole repository – only the chunk of code you are committing.
Yelp’s detect-secrets, however, has its limitations. It needs to be installed locally by engineers which might be tricky with different operating systems. If you do want to use it but don’t want to be restricted by local installation, it can also run out of a container, which can be quite handy.