Time for something new
Posted: June 6, 2019 Filed under: Agile, Career Opportunities, Cyber, Skills Development | Tags: Cyber Leave a commentAfter six years with KPMG’s Cyber Security practice I decided it was time to take on a new challenge. It was a great pleasure helping clients from various industry sectors solve their security issues and I certainly learned a lot and met many fantastic people.
BCG Digital Ventures, an incubation firm that’s part of Boston Consulting Group, has partnered with VFS Global, a world leader in visas and identity management, to found a new London-based venture that is creating a frictionless travel experience.
I joined this tech startup as the Head of Information Security and couldn’t pass on this opportunity to be one of the early members of the leadership team.
I’ll be driving the security and compliance agenda, adjusting to the needs of the dynamic and growing business. I can’t wait to put the skills I learned in consulting into practice and contribute to this company.
I’ll have an opportunity to help create a trusted, seamless, user centred visa application process for consumers and businesses alike, through automation and a cutting edge technology. And that’s exciting!
ISACA young professionals
Posted: June 2, 2019 Filed under: Audit, Career Opportunities, Information Security, Interview, Skills Development | Tags: Cyber Leave a commentI’ve been interviewed for the launch of the ISACA Young Professionals portal that contains a wealth of information for starting and accelerating your career in IT audit and cybersecurity.
I decided to contribute because ISACA played a role in my career development too.
I started attending ISACA London chapter events while I was studying for my Master’s degree in London. Although the university provided a great theoretical foundation on information security, I wanted to know about the real-world challenges that practitioners in the industry were facing.
At the time I had just finished writing my thesis after doing some great research at the university and I wanted to share my findings and the research of my colleagues with the community. The organisers were supportive, so we agreed a day and I delivered a talk on resolving conflicts between security compliance and human behaviour.
It was a rewarding experience as the participants provided some valuable insights and feedback; they helped to bridge the gap between academia and real practical experience. I already had a solid foundation from my postgraduate degree but I was missing was some anecdotes and real life stories about how this could apply in practice. This laid the foundation for my book The Psychology of Information Security.
It worked out for me, but should you get involved in broader activities beyond developing your technical skills? I would say yes.
The value of technical skills and knowledge can’t be overestimated. But there’s another side to this story. Prospective employers are not only looking for technical experts, they want people who are good team players, who can collaborate and communicate effectively with others, who can organise and get things done, who can lead. Getting involved with the community and volunteering gives you the chance to develop and demonstrate these non-technical skills and grow your professional network.
Regardless of where you are on your journey, ISACA provides great opportunities to advance your career through courses, networking and certification programmes, so I highly recommend getting involved!
Read my story on ISACA Blog.
What can a US Army General teach us about security?
Posted: May 25, 2019 Filed under: Productive Security, Security Culture, Security Strategy, Team Leadership | Tags: Cyber, Productive Security, Security Awareness, Security Culture Leave a comment
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.
Vulnerability scanning gone bad
Posted: May 17, 2019 Filed under: Compliance, Information Security Management, Productive Security, Security Culture | Tags: Productive Security, Security Culture Leave a comment
Security teams often have good intentions when they want to improve the security posture of a company by introducing new tools.
In one organisation, for example, they might want to mitigate the risk of exploiting application vulnerabilities and decide to deploy a code-scanning tool. This would make sure that applications are tested for exploits before they are released. Great idea but the uptake on the use of this tool was surprisingly low and created a lot of friction.
After closer examination, it turns out that this was primarily due to challenges with communication with the development teams that would need to use the tool. The impacted teams weren’t sufficiently trained on the use of it and there wasn’t enough support from the management to adopt it.
Development teams have tight timelines and budgets to work to in order to meet the business objectives. Anything that could disrupt these aspects is viewed with caution.
As a result, applications that should have had their code scanned either hadn’t, or had to be scanned at a much later stage of the development cycle. It was not incorporated in the DevOps pipeline– the scans were run as part of a manual check before release in production. Not only the risk of having applications with flaws in them remain largely unchanged, the whole process of delivering working software was prolonged.
These new applications were being delivered to facilitate revenue growth or streamline exiting processes to reduce cost and complexity. The impact on the business was that the new functionality they were expecting took longer to materialise, resulting in users’ frustration.
What can you do to prevent such situations from happening? Here are a few recommendations:
- Communicate frequently and at the right level. Communication must start at the top of an organisation and work its way down, so that priorities and expectations can be aligned. A person may need to hear the same message multiple times before they take action.
- Articulate the benefits. Security and risk teams need to ensure they position any new processes or tools in a way that highlights the benefits to each stakeholder group.
- Provide clear steps. In order to ensure the change is successful, security professionals should clearly outline the steps for how to start realising these benefits.
Communicating and providing support on new security policies, tools and practices to impacted teams is absolutely critical. This is especially important in large organisations with many stakeholder groups spread across multiple geographies. Always keep the people in mind when introducing a change, even if it’s the one for the better.
Image by Hugo Chinaglia
Transparency in security
Posted: May 10, 2019 Filed under: Conference, Cryptography, Cyber, Information Security Management, Presentations, Research | Tags: Cyber, Productive Security Leave a comment
I was asked to deliver a keynote in Germany at the Security Transparent conference. Of course, I agreed. Transparency in security is one of the topics that is very close to my heart and I wish professionals in the industry not only talked about it more, but also applied it in practice.
Back in the old days, security through obscurity was one of the many defence layers security professionals were employing to protect against attackers. On the surface, it’s hard to argue with such a logic: the less the adversary knows about our systems, the less likely they are to find a vulnerability that can be exploited.
There are some disadvantages to this approach, however. For one, you now need to tightly control the access to the restricted information about the system to limit the possibility of leaking sensitive information about its design. But this also limits the scope for testing: if only a handful of people are allowed to inspect the system for security flaws, the chances of actually discovering them are greatly reduced, especially when it comes to complex systems. Cryptographers were among the first to realise this. One of Kerckhoff’s principles states that “a cryptosystem should be secure even if everything about the system, except the key, is public knowledge”.
Modern encryption algorithms are not only completely open to public, exposing them to intense scrutiny, but they have often been developed by public, as is the case, for example, with AES. If a vendor is boasting using their own proprietary encryption algorithm, I suggest giving them a wide berth.
Cryptography aside, you can approach transparency from many different angles: the way you handle personal data, respond to a security incident or work with your partners and suppliers. All of these and many more deserve attention of the security community. We need to move away from ambiguous privacy policies and the desire to save face by not disclosing a security breach affecting our customers or downplaying its impact.
The way you communicate internally and externally while enacting these changes within an organisation matters a lot, which is why I focused on this communication element while presenting at Security Transparent 2019. I also talked about friction between security and productivity and the need for better alignment between security and the business.
I shared some stories from behavioural economics, criminology and social psychology to demonstrate that challenges we are facing in information security are not always unique – we can often look at other seemingly unrelated fields to borrow and adjust what works for them. Applying lessons learned from other disciplines when it comes to transparency and understanding people is essential when designing security that works, especially if your aim is to move beyond compliance and be an enabler to the business.
Remember, people are employed to do a particular job: unless you’re hired as an information security specialist, your job is not to be an expert in security. In fact, badly designed and implemented security controls can prevent you from doing your job effectively by reducing your productivity.
After all, even Kerckhoff recognised the importance of context and fatigue that security can place on people. One of his lesser known principles states that “given the circumstances in which it is to be used, the system must be easy to use and should not be stressful to use or require its users to know and comply with a long list of rules”. He was a wise man indeed.
Understanding your threat landscape
Posted: May 6, 2019 Filed under: Cyber, Information Security Management, Risk Management, Threat Model | Tags: Cyber, Risk, Threat Model Leave a commentIdentifying applicable threats is a good step to take before defining security controls your organisation should put in place. There are various techniques to help you with threat modelling but I wanted to give you some high-level pointers in this blog to get you started. Of course, all of these should be tailored to your specific business.
I find it useful to think about potential attacks as three broad categories:
1. Commoditised attacks. Usually not targeted and involve off-the-shelf-malware. Examples include:
- Ransomware (Maersk ransomware attack)
- Crypto mining (Hackers enlisted Tesla’s public cloud to mine cryptocurrency)
- Denial of service (Biggest-Ever DDoS Attack (1.35 Tbs) Hits Github Website)
2. Tailored attacks. As the name suggests, these are tailored and can vary in degree of sophistication. Examples include:
- Business email compromise (Online money transfer provider Xoom suffers multimillion-dollar fraud)
- Retail website breach (British Airways data breach)
- Data exfiltration (Private data of 500 million Marriott guests exposed in massive breach)
3. Accidental. Not every data breach is triggered by a malicious actor. Therefore, it is important to recognise that mistakes happen. Unfortunately sometimes they lead to undesired consequences, like the below:
- Human error (London Sexual Health Clinic Fined £180,000 for Data Breach)
- Insecure engineering practices (The NHS is blaming a coding error for 150,000 patients in England being involved in a data breach)
- Mishandling of data (Personal details of as many as 500 NHS doctors were exposed after an internal spreadsheet containing their details was published online)
Information security professionals can use the above examples in communications with their business stakeholders not to spread fear, but to present certain security challenges in context.
It’s often helpful to make it a bit more personal, defining specific threat actors, their target, motivation and impact on the business. Again, the below table serves as an example and can be used as a starting point for you define your own.
| Threat actor | Description | Motivation | Target | Impact on business |
| Organised crime | International hacking groups | Financial gain | Commercial data, personal data for identity fraud | Reputational damage, regulatory fines, loss of customer trust |
| Insider | Intentional or unintentional | Human error, grudge, financial gain | Intellectual property, commercial data | Destruction or alteration of information, theft of information, reputational damage, regulatory fines |
| Competitors | Espionage and sabotage | Competitive advantage | Intellectual property, commercial information | Disruption or destruction, theft of information, reputational damage, loss of customer |
| State-sponsored | Espionage | Political | Intellectual property, commercial data, personal data | Theft of information, reputational damage |
You can then use your understanding of assets and threats relevant to your company to identify security risks. For instance:
- Failure to comply with relevant regulation – revenue loss and reputational damage due to fines and unwanted media attention as a result of non-compliance with GDPR, PCI DSS, etc.
- Breach of personal data – regulatory fines, potential litigation and loss of customer trust due to accidental mishandling, external system compromise or insider threat leading to exposure of personal data of customers
- Disruption of operations – decreased productivity or inability to trade due to compromise of IT systems by malicious actor, denial of service attacks, sabotage or employee error
Again, feel free to use these as examples, but always tailor them based on what’s important you your business. It’s also worth remembering that this is not a one-off exercise. Tracking your assets, threats and risks should be part of your security management function and be incorporated in operational risk management and continuous improvement cycles.
This will allow you to demonstrate the value of security through pragmatic and prioritised security controls, focusing on protecting the most important assets, ensuring alignment to business strategy and embedding security into the business.
Cyber security in divestments
Posted: May 2, 2019 Filed under: Cyber, Information Security Management, Risk Management | Tags: Cyber Leave a comment
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.
