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.
I bet you already know that you should enable CloudTrail on your AWS accounts, if you haven’t yet. This service captures all the API activity taking place in your AWS account and stores it in an S3 bucket for that account by default. This means you would have to configure the logging and storage permissions for every AWS account your company has. If you are tasked with securing your cloud infrastructure, you will first need to establish how many accounts your organisation owns and how CloudTrail is configured for them. Additionally, you would want to have access to S3 buckets storing these logs in every account to be able to analyse them.
If this doesn’t sound complicated already, think of a potential error in permissions where logs can be deleted by an account administrator. Or situations where new accounts are created without your awareness and therefore not part of the overall logging pipeline. Luckily, these scenarios can be avoided if you are using the Organization Trail.
Your accounts have to be part of the same AWS Organization, of course. You also would need to have a separate account for security operations. Hopefully, this has been done already. If not, feel free to refer to my previous blogs on inventorying your assets and IAM fundamentals for further guidance on setting it up.
Establishing an Organization Trail not only allows you to collect, store and analyse logs centrally, it also ensures all new accounts created will have CloudTrail enabled and configured by default (and it cannot be turned off by child accounts).
Switch on Insights while you’re at it. This will simply the analysis down the line, alerting unusual API activity. Logging data events (for both S3 and Lambda) and integrating with CloudWatch Logs is also a good idea.
Where can all these logs be stored? The best destination (before archiving) is the S3 bucket in your account used for security operations, so that’s where it should be created.
Enabling encryption and Object Lock is always a good idea. While encryption will help with confidentiality of your log data, Object Lock will ensure redundancy and prevent objects from accidental deletion. It requires versioning to be enabled and is best configured on bucket creation. Don’t forget to block public access!
You will then must to use your organisational root account to set up Organization Trail, selecting the bucket you created in your operational security account as a destination (rather than creating a new bucket in your master account).
If you had other trails in your accounts previously, feel free to turn them off to avoid unnecessary duplication and save money. It’s best to give it a day for these trails to run in parallel though to ensure nothing is lost in transition. Keep your old S3 buckets used for collection in your accounts previously; you will need these logs too. You can configure lifecycle policies and perhaps transfer them to Glacier to save on storage costs later.
And that’s how you set up CloudTrail for centralised collection, storage and analysis.
If you work for or (even better) co-founded a tech startup, you are already busy. Hopefully not too busy to completely ignore security, but definitely busy enough to implement one of the industrial security frameworks, like the NIST Cybersecurity Framework (CSF). Although the CSF and other standards are useful, implementing them in a small company might be resource intensive.
I previously wrote about security for startups. In this blog, I would like to share some ideas for activities you might consider (in no particular order) instead of implementing a security standard straight away. The individual elements and priorities will, of course, vary depending on your business type and needs and this list is not exhaustive.
Information security underpins all products and services to offer customers an innovative and frictionless experience.
- Improve product security, robustness and stability through secure software development process
- Automate security tests and prevent secrets in code
- Upgrade vulnerable dependencies
- Secure the delivery pipeline
Cloud infrastructure security
To deliver resilient and secure service to build customer trust.
- Harden cloud infrastructure configuration
- Improve identity and access management practices
- Develop logging and monitoring capability
- Reduce attack surface and costs by decommissioning unused resources in the cloud
- Secure communications and encrypt sensitive data at rest and in transit
To prevent regulatory fines, potential litigation and loss of customer trust due to accidental mishandling, external system compromise or insider threat leading to exposure of customer personal data.
- Enable device (phone and laptop) encryption and automatic software updates
- Make a password manager available to your staff (and enforce a password policy)
- Improve email security (including anti-phishing protections)
- Implement mobile device management to enforce security policies
- Invest in malware prevention capability
- Segregate access and restrict permissions to critical assets
- Conduct security awareness and training
To prepare for, respond to and recover from cyber attacks while delivering a consistent level of service to customers.
- Identify and focus on protecting most important assets
- Develop (and test) an incident response plan
- Collect and analyse logs for fraud and attacks
- Develop anomaly detection capability
- Regular backups of critical data
- Disaster recovery and business continuity planning
Compliance and data protection
To demonstrate to business partners, regulators, suppliers and customers the commitment to security and privacy and act as a brand differentiator. To prevent revenue loss and reputational damage due to fines and unwanted media attention as a result of GDPR non compliance.
- Ensure lawfulness, fairness, transparency, data minimisation, security, accountability, purpose and storage limitation when processing personal data
- Optimise subject access request process
- Maintain data inventory and mapping
- Conduct privacy impact assessments on new projects
- Data classification and retention
- Vendor risk management
- Improve governance and risk management practices
Image by Lennon Shimokawa.
Let’s build on my previous blog on inventorying your AWS assets. I described how to use CloudMapper‘s collect command to gather metadata about your AWS accounts and report on resources used and potential security issues.
This open source tool can do more than that and it’s functionality is being continuously updated. Once the data on the accounts in scope is downloaded, various operations can be performed on it locally without the need to continuously query the accounts.
One of interesting use cases is to visualise your AWS environment in the browser. An example based on the test data of such a visualisation is at the top of this blog. You can apply various filters to reduce complexity which can be especially useful for larger environments.
Another piece of CloudMapper’s functionality is the ability to display trust relationships between accounts using the weboftrust command. Below is an example from Scott’s guidance on the use of this command. It demonstrates the connections between accounts, including external vendors.
I’m not going co cover all the commands here and suggest checking the official GitHub page for the latest list. I also recommend running CloudMapper regularly, especially in environments that constantly evolve.
An approach of that conducts regular audits. saving reports and integrating with Slack for security alerts is described here.
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.