Welcoming to Archangel's blog - Guest Author: Peter Freiberg
----------
Often, security is seen as a nebulous and broad “thing” that needs to be done but feels complex and expensive. I’ll aim to give you some practical guidance for founders that I’ve found relevant in my work with startups and scale-ups at the pointy end of software and application security.
Security more generally
Startups are full of uncertainty and risk. Security risks might not always be top of mind when you are trying to prove you have a product that the market might actually pay for, but security risks are always there, particularly if trust is important to selling your product or service or specifically where customers ask you security-related questions about your business before they will make a purchase.
In large organisations, there’s often a policy or framework that “has to be followed”. However, not all large-scale processes and frameworks “scale down” to smaller companies. Even compliance obligations *might* be different depending on your organisation's size.
What you need for 10,000 people will be different for 10 people. Know your industry and its norms - if you are tightly regulated, you will be held to a higher standard.
Security is a big topic in itself and here are some thoughts on what smaller organisations might want to be thinking about:
- Things you use (laptops, mobiles, code)
- Your application or service (code, cloud environment, dev tools)
- Business apps you use (mail, payroll, collaboration)
- Your people (staff, partners, subcontractors etc.)
- Your responsibilities to shareholders, staff and other governing bodies.
- Customers
With this in mind, we will focus on the first two points above, which have to do with application security.
Focus areas for security in organisations that build software
Below, I’ll cover some core areas including:
- Educating yourself on security
- Leveraging industry and vendor standards
- Automate your security testing where possible
- Test specific use cases
- Password management tips
- Using 2FA for key services
- Monitoring and logging
- Protect your endpoints (e.g. laptops)
- Security (cyber) risk is part of your overall risk appetite equation
- Identify who you’re going to call in an incident
1. Education: Learn about software flaws, vulnerabilities and good practices
The Open Web Application Security Project (OWASP) has been around for over twenty years, often used as a de facto standard for application security awareness. Are you:
- Building a web app? Check out the OWASP Top 10 for Web Apps.
- Building a mobile app? Check out the OWASP Top 10 for Mobile Apps.
- Building an API? Check out the OWASP Top 10 for APIs.
- Needing to start security testing? Check out the OWASP Security Testing Guide.
Read and understand your key risks and document your processes.
2. Industry and vendor standards
Often, languages and frameworks will have their own security guides. Find them for your technology stack and incorporate them into your development practices.
Vendors may have security practice guides too, such as Google Cloud Security best practices, AWS Best Practices and GitHub Security.
Ask for help if you don’t understand them - vendors are often more than willing to help.
Document what you use and find relevant security guides. Iterate on your knowledge from there.
3. Use security test automation where possible
Many security tests can be automated. There are a few common categories of security testing tools fraught with acronyms. The AppSec alphabet soup article does a pretty good job of explaining the common security testing categories. There’s also a more recent category called SCA (Software Composition Analysis) which finds vulnerabilities in open-source libraries, from public databases and research. GitHub describes and compares some differences in the article SCA vs SAST.
For most organisations, testing your application and technology stack falls into these categories:
- Secrets detection and management - avoiding hard-coded credentials in code and configuration
- Your source code and using SAST (Static Application Security Testing)
- Open-source libraries and using SCA (Software Composition Analysis)
- Docker images and Virtual machines and using SCA and vulnerability management tools
- IaC - Checking for common issues, compliance, secrets and drift
Which tool should you use? It depends on your technology stack, current development tools, and your industry requirements. There’s some good free stuff to start, but often a commercial tool from GitHub GHAS, Checkmarx, Synopsis or Snyk is used in enterprises to get better coverage and support.
4. Test for cases specific to you (automate if possible)
Building good automated testing takes time and needs to be maintained. If you can’t automate, at least plan for how you will manually test for situations that should not happen.
Some examples of items to test for:
- Customer X should not be able to see Customer Y’s data
- Privacy data should not be logged
- Transaction limits should be enforced
- Known vulnerabilities (OWASP TOP 10, open source) with automation
Testing for things that you DON’T want to happen is important. Something can be functional but insecure. Remember that this testing is in addition to your unit, integration, usability and performance testing.
5. Keep your passwords safe (use a manager)
According to a recent study, the average person has 70-80 passwords - life is increasingly online and behind a password. The typical startup might have 20-30 online accounts, passwords or tokens spread across banking, accounting, online services and store these passwords in different locations (unless they use single sign-on from Office365 or Google workspace).
Password managers help with “remembering” strong passwords - recently I’ve noticed people and organisations using 1password. Having more robust security using a password manager is the way to go. Stop using spreadsheets and notes!
Keep passwords out of code. I’ve seen cases where Amazon keys were found in public git code repositories. The bad guys use these keys to spin up compute and do bitcoin mining at thousands of dollars per hour at a cost to the company that owned the code.
6. Use 2FA where possible (and useful)
Most applications have 2FA available for administration consoles and additional account security. 2FA is a good measure to help combat phishing attacks and protect your accounts better. While 2FA requires set-up, it will help protect your accounts.
Be vigilant about where you give your 2FA. Many social engineering attacks will ask for your 2FA over the phone or via chat and SMS.
7. Don’t forget logging. Monitor what’s happening.
What’s your application doing? What features are your customers using the most? What’s going wrong?
Generally, application logs are error driven to identify bugs, but it’s essential to implement some user behaviour logging to help determine what “good users look like” to detect “bad”.
8. What’s going on with your endpoints or laptops?
What happens if you lose your laptop or phone? What data or Intellectual property would be lost? Are passwords or credentials that could be used to access email or banking on a device?
Again, your vendors will have security guidelines for laptops, operating systems and phones. Use vendor guidelines and ensure features like full disk encryption are enabled, and you have some type of endpoint protection to handle malware and suspicious activity.
9. Cyber risk feeds into normal business risk
Understanding your business risk is essential in identifying cyber risks. To understand your cyber risk, you need to know your business risk appetite around asset value, tolerance for outages, financial loss thresholds, key person risks, etc. Good risk management processes and documentation allow for managing all risks, not just cyber. One of the first decisions many startups have to make is whether to insure for cyber risks.
Something which may help with identifying risk is keeping track of your systems and business applications, how you log on and what data is in there. Questions like, what would someone attack this or us for? Could it be used for fraud? Identify theft? Are we a target because our data is valuable for other malicious activity? (e.g. are your customers high net worth)
10. Who are you going to call (when something goes wrong)?
More than likely, something is going to go wrong. Maybe it's a breach, successful phishing scam, invoice fraud or malware outbreak. Find a company or service now that can help out if something happens. It may be hard to find someone good at short notice when you are in the middle of an incident.
Thoughts on next steps
There’s always lots to do in a business, and security is one more on the list. Making it a part of regular activities keeps the risk lower, rather than “annual assessments”. I’ve seen this work from simply adding security and risk questions to user stories, backlog grooming and sprint planning. Another option is to engage a fractional security specialist until you can budget for hiring your own people. The key point is to start and keep iterating on things you can do and engage specialist help when needed.
----------
Peter is a DevSecOps and application security consultant based in Melbourne, Australia, who specialises in Application Security and DevSecOps. Peter has built teams and capabilities for organisations around Penetration Testing (ethical hacking), Secure Code Reviews, DevSecOps, Security Test Automation, Security Development Lifecycle and training.
