Netrunner: what infosec might look like in the future
Posted: December 4, 2019 Filed under: Cyber, Penetration Test, Skills Development, Threat Model | Tags: Gamification Leave a comment
Android: Netrunner is a two-player card game that can teach you a great deal about cyber security. It’s fun to play too.
Bad news first: although initially intended as a ‘living card game’ with constantly evolving gameplay, this game has now been discontinued, so no expansions will be published, limiting the community interest, ongoing deckbuilding and tournaments.
Now to the good news, which is pretty much the rest of this blog. None of the above can stop you from enjoying this great game. You can still acquire the initial core set which contains all you need for casual play.
The premise of this game is simple: mega corporations control all aspects of our lives and hackers (known as runners) oppose them. I know it was supposed to be set in the dystopian cyberpunk future, but some of the elements of it are coming to life sooner than expected since the original game release in 1996.
The runners vary in their abilities that closely align to their motivation: money, intellectual curiosity, disdain for corporations. Corporations have their core competencies too. Again, just like in real life. The core set I mentioned earlier consists of seven pre-built, and balanced by creators, decks: three for runners and four for corporations with their unique play styles.
The game is asymmetrical with different win conditions: runners are trying to hack into corporations’ networks to steal sensitive information (known as agendas in the game) and corporations are aiming to defend their assets to achieve their objectives (advance agendas). This masterfully highlights the red team versus blue team tension commonplace in today’s infosec community.
A corporation has to adapt to evolving threats posed by hackers installing protective devices and conducting defensive operations all the while generating revenue to fund these projects and reach their targets to win the game. It’s not only about defence for the corporation either. Today’s “hacking back” debate got apparently settled in the future, with corporations being able to trap, tag and trace hackers to inflict real damage, as an alternative win condition.
Runners differ vastly in methods to penetrate corporation’s defences and have to take care of an economy of their own: all these cutting edge hacking consoles cost money and memory units. Example cards in runner’s toolbox sometimes closely resemble modern methods (e.g. siphoning off corp’s accounts) and sometimes gaze far into the future with brain-machine interfaces to speed up the process.
Basic rules are simple but there are plenty of intricate details that make players think about strategy and tactics. It’s a game of bluff, risk and careful calculation. There’s also an element of chance in it, which teaches you to be able to make the best use of resources you currently have and adapt accordingly.
It’s not an educational game but you can learn some interesting security concepts while playing, as you are forced to think like a hacker taking chances and exploiting weaknesses or a defender trying to protect your secrets. All you need is the deck of cards and someone to play with.
The Complexity of Risk Management – free audiobook chapter
Posted: December 2, 2019 Filed under: Information Security Management, Risk Management, Security Culture Leave a commentMy publisher kindly made one of the chapters of my audiobook available for free. In it, I discuss the role of uncertainty in making decisions and managing risk.
Agile security. Part 2: User stories
Posted: December 2, 2019 Filed under: Agile, Cyber, Software Security | Tags: Agile, Cyber, DevSecOps, Product management 1 Comment
In the previous blog, I wrote about how you as a security specialist can succeed in the world of agile development, where the requirements are less clear, environment more fluid and change is celebrated not resisted.
Adjusting your mindset and embracing the fact that there will be plenty of unknowns is the first step in adopting agile security practices. You can still influence the direction of the product development to make it more resilient, safe and secure by working with the Product Owner and contributing your requirements to the product backlog.
Simply put, product backlog is a list of desired functionality, bug fixes and other requirements needed to deliver a viable product. There are plethora of tools out there to help manage dependencies and prioritisation to make the product owner’s job easier. The image at the top of this post is an example of one of such tools and you can see some example requirements there.
As a security specialist, you can communicate your needs in a form of user stories or help contribute to existing ones, detailing security considerations. For example, ”Customer personal data should be stored securely” or “Secure communication channels should be used when transmitting sensitive information”. Below are a couple more examples from different categories.
When writing security user stories, you should try and elaborate as much as possible on the problem you are trying to solve, what value it will provide if solved and the acceptance criteria. Each story will then have points assigned which signifies how much effort a particular functionality will require. The process of arriving to the final number is quite democratic and usually involves playing planning (sometimes also called Scrum) poker in which every developer will estimate how long each story is going to take with some discussion and eventual consensus. You can do it with an app as on the image below, or the old school way with a deck of cards.
You don’t have to use the above number pattern, and opt-in instead for the Fibonacci sequence or T-shirt sizes.
It’s important that the security team is involved in sprint planning to contribute to the estimates and help the product owner with prioritisation. Other Scrum meetings, like backlog refinement and daily stand-ups are also worthwhile to attend to be able clarify your requirements (including value, risk, due dates and dependencies) and help remove security related impediments.
A culture of collaboration between teams is essential for the DevSecOps approach to be effective. Treating security as not something to workaround but as a value adding product feature is the mindset product and engineering teams should adopt. However, it’s up to security specialists to recognise the wider context in which they operate and accept the fact that security is just one of the requirements the team needs to consider. If the business can’t generate revenue because crucial features that customers demand are missing, it’s little consolation that security vulnerabilities have been addressed. After all, it’s great to have a secure product, but less so when nobody uses it.
Agile security. Part 1: Embedding security in your product
Posted: December 2, 2019 Filed under: Agile, Cyber, Information Security | Tags: Agile, Cyber, DevSecOps, Product management, Security 1 Comment
Outline security requirements at the beginning of the project, review the design to check if the requirements have been incorporated and perform security testing before go-live. If this sounds familiar, it should. Many companies manage their projects using the waterfall method, where predefined ‘gates’ have to be cleared before the initiative can move forward. The decision can be made at certain checkpoints to not proceed further, accepting the sunk costs if benefits now seem unlikely to be realised.
This approach works really well in structured environments with clear objectives and limited uncertainty and I saw great things being delivered using this method in my career. There are many positives from the security point of view too: the security team gets involved as they would normally have to provide their sign-off at certain stage gates, so it’s in the project manager’s interest to engage them early to avoid delays down the line. Additionally, the security team’s output and methodology are often well defined, so there are no surprises from both sides and it’s easier to scale.
If overall requirements are less clear, however, or you are constantly iterating to learn more about your stakeholder’s needs to progressively elaborate on the requirements, to validate and perhaps even pivot from the initial hypothesis, more agile project management methodologies are more suitable.
Embedding security in the agile development is less established and there is more than one way of doing it.
When discussing security in startups and other companies adopting agile approaches, I see a lot of focus on automating security tests and educating developers on secure software development. Although these initiatives have their merits, it’s not the whole story.
Security professionals need to have the bigger picture in mind and work with product teams to not only prevent vulnerabilities in code, but influence the overall product strategy, striving towards security and privacy by design.
Adding security features and reviewing and refining existing requirements to make the product more secure is a step in the right direction. To do this effectively, developing a relationship with the development and product teams is paramount. The product owner especially should be your best friend, as you often have to persuade them to include your security requirements and user stories in sprints. Remember, as a security specialist, you are only one of the stakeholders they have to manage and there might be a lot of competing requirements. Besides, there is a limited amount of functionality the development can deliver each sprint, so articulating the value and importance of your suggestions becomes an essential skill.
Few people notice security until it’s missing, then the only thing you can notice is the absence of it. We see this time and time again when organisations of various sizes are grappling with data breaches and security incidents. It’s your job to articulate the importance of prioritising security requirements early in the project to mitigate the potential rework and negative impact in the future.
One way of doing this is by refining existing user stories by adding security elements to them, creating dedicated security stories, or just adding security requirements to the product backlog. Although the specifics will depend on you organisation’s way of working, I will discuss some examples in my next blog.
[Podcast] Interview about The Psychology of Information Security
Posted: November 30, 2019 Filed under: Interview, Productive Security, Security Culture | Tags: Security Culture Leave a commentI’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
Posted: November 29, 2019 Filed under: Agile, Cyber, Software Security | Tags: Agile, Cyber, DevSecOps 1 CommentWe 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
Posted: November 25, 2019 Filed under: Agile, Cyber, Software Security | Tags: Agile, Cyber, DevSecOps 1 CommentWe 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.
