Security is Everything
If you're thinking about security for your company, but you don't know where to start, then you've come to right place.
Security spans the entirety of your company, all the way from how you onboard employees to the dependencies you import, but adding security comes at a cost: More secure systems are often more complicated to use.
Given that tradeoff, which areas of security should you focus on first?
We'll be answering that question today, based on our conversations with hundreds of companies, and we'll be offering our advice about how you can balance between security and usability as you grow.
What is Security vs Usability?
The easiest way to answer this question is with a real-world example:
When my colleague lived in downtown San Francisco, he would always make sure to lock the door to his car at night and make sure that he had nothing inside that might tempt a thief to break his window.
But, when I lived in the country, I would leave my car unlocked and even with the keys in the ignition!
I certainly saved a lot of time not having to hunt around for my keys every time I needed to get groceries, but it's immediately obvious that my car wasn't as "secure" as his.
But, while I was able to skip out on security for years without any repercussions, my colleague made sure to lock his car every night because, the few times he forgot, somebody would rummage through his car and make a mess if he didn't.
That's the important thing to remember with security: There is never a one-size-fits-all solution because every company's risk level is different.
You will always be vulnerable
Reality is cruel: To be 100% secure is impossible and a sufficiently motivated attacker will almost always be able to get what they want from your company.
And not only are you never going to be totally secure, but, even if you wanted to be, there is simply not enough cybersecurity talent to defend the world's infrastructure.
Together, the Cybersecurity Workforce Estimate and Cybersecurity Workforce Gap suggest the global cybersecurity workforce needs to grow 65% to effectively defend organizations’ critical assets. ~ ISC2 Cybersecurity Workforce Study
That's why, regardless of the size of your company, it's critical for security teams to have a carefully thought out plan to prioritize which assets they need to protect the most.
One of the best resources available is the OWASP SAMM model, but, while it's extremely in depth about many areas of security, it's also complicated and not the best place place to start for smaller teams.
We're going to be taking OWASP SAMM and breaking into clear action items along with relevant resources such has Open Source and Commerical tools to kick start your own journey to adding security to your company.
We are the developers of the supply chain defense tool LunaTrace. It's an easy way to add security to your code (for free) in 1-2 minutes just by adding our GitHub App to your projects.
Any tools or service recommendations made in this post are based on our opinions. Review these recommendations yourself to understand what tools or services would work best for your company.
Identify objectives and means of measuring effectiveness of the security program.
Like any organized and healthy team, a strategy and quantifiable metrics are needed to understand how effectively a team is at addressing the problem space. Unfortunately, in security, measurable metrics are often promised in automated tools, but far too often under deliver in actual value to an organization.
- To address metrics that are potential over-fitted for security, having a conversation with leadership about risk tolerance, or what bad scenarios are actually really bad for the company, is a great way to focus on things that matter.
- Create a list of metrics, based on the really bad scenarios, that are manageable for the size of the security team at your company. Creating good metrics can be difficult and are not one-size-fits-all.
Security Metric Guidelines
A good security metric is one that can always be measured, preferably automatically in a dashboard, but a good ol' SQL query or bash script that can be put into a spreadsheet will do the job too.
Every security metric should fall into the category of:
- Effort spent on security - Number/Percent of X that have been Y.
- Number of hours that have been spent training developers on security best practices.
- Number of applications that have been code reviewed.
- Percent of services that have been scanned for vulnerabilities.
- Result of security efforts - By doing X, the number/percent of Y.
- By identifying security defects in projects, the number of patches that have not been resolved.
- By performing root cause analysis, the percent of security investigations that were identified to be caused by an application vulnerability.
- Environment the security team operates in - Number/Percent of X in the Y.
- Number of managed devices in the company.
- Percent of teams in the organization using a cloud provider.
Depending on what data your company collects, there may be regulatory requirements for how that is done. For example, if you collect information about a user's medical records, your company must handle this data in a HIPAA compliant way. Understanding what compliance requirements affect your company is imperative if you wish to avoid massive fines. Often times when working with other companies that handle Personal Data themselves, you might be requested to present evidence of an 3rd-party audit, such as SOC 2.
- Catalogue what data you are collecting and understand what data you are collecting is considered Personal Data. Match this data that you are collecting up to compliance requirements.
- Depending on how essential collecting Personal Data is to your company, consider contacting a company that specializes in compliance requirements, such as Vanta, to help you understand these compliance requirements better.
Common Compliance Standards
- GDPR (General Data Protection Regulation)
- HIPAA (Health Insurance Portability and Accountability)
- PCI DSS (Payment Card Industry Data Security Standard)
- CCPA (California Consumer Privacy Act)
- SOC 2 (System of Organization Controls)
Note on Compliance Standards
This is not an exhaustive list of standards, there may be more depending on what country you intend on operating in.
Informing developers about security best practices is not just about protecting code from trivial mistakes . Engineers who design systems with security in mind effortlessly makes your company 10x more secure now and in the future.
It can be difficult to provide education that is relevant to a developer's day-to-day job without hiring someone to provide bespoke guidance based on your tech stack. The best guidance that a security engineer can truly give to a developer is simple: "ask questions". Encourage developers to ask questions about how secure a stack is and poke holes in how infrastructure is built. Dedicating time to let developers research answers to their security questions will save time and money in the long run.
- Have developers review the OWASP Top 10 list of commonly exploited vulnerabilities and understand how they can be mitigated.
- Make sure developers are familiar with the top 10 most commonly exploited web application vulnerabilities identified by HackerOne.
To know your enemy, you must become your enemy. ~ Sun Tzu
To perform a meaningful threat assessment means to ask your developers to shift their perspective from writing features, to playing hacker on their own code. The expectation should never be for a developer to take the place of a penetration tester, but as the people who are most intimate with details of how the system works, they are the best suited to answer critical security questions.
For each project that exists, have each team responsible create an Application Risk Profile where relevant security questions are answered to categorize the service's level of risk.
Create a Threat Model of your infrastructure and identify weaknesses, or places an attacker could possibly gain access. It not important for this process to initially be thorough, as software for a company in growth is constantly changing. Instead, focus on what parts of company are the "keys to the castle" and understand how an attacker could obtain them. Diagrams are your friend. Get in a call with your team and collaboratively work on a Google Jamboard or Lucidchart to sketch out your infrastructure.
Before writing any code, security should always be considered. A system that is build with intelligent security design choices beforehand will be "secure by default" and continually protect your services from potential compromise. Similar to the Threat Assessment section, it is not important for this to be thorough to start. It is also important to note that if you are dealing with Personal Data and will need to meet some compliance standard, letting those requirements drive some part of your roadmap early on will enable your team to confidently clear an audit without disrupting feature development.
- When planning features for a project, allocate time to answer the question "What are the security requirements of what is being built?". Using OWASP's ASVS can help your team identify what those considerations would be based on what is being built.
- If 3rd party vendors are handling critical data for your company, perform a Vendor Security Review to understand if their company follows similar security practices to yours.
Translating Secure Requirements to tasks on a roadmap can be challenging, especially for teams without developers experienced in security. Identifying frameworks that are well-designed, actively developed, and built with security in mind will put wind in your team's sails. There will be more documentation reading and less "wheel re-inventing" if answers to common security questions are readily available.
For example, React or Vue are popular web frameworks that provide a number of "secure by default" features to prevent the most common web application vulnerability, XSS. Recommending a cryptography library, such as Google Tink or LibSodium will enable developers to tackle, the otherwise challenging task, of encrypting data to meet compliance requirements. Cloud providers, such as AWS, GCP, Azure, etc., all have security controls that can be configured to isolate and protect services from each other in the case of a compromise.
- For common types of projects that your company might develop (ie. a frontend website, backend microservice, etc.) identify and recommend frameworks that have been vetted to be both functional and secure.
- Promote the use of a secrets manager when secrets are needed in code. Most cloud providers offer an integrated service to make this trivial to do. For example, AWS has the AWS Secrets Manager.
Continually building your project (a.k.a. Continuous Integration or CI) is essential in the age of rapid development. Having CI means that automated security checks can easily be integrated, but more importantly it means that security fixes can be written, tested, and verified automatically.
- Strive to make all builds repeatable. Having a design pattern accessible to developers, when creating new projects, will greatly help this process. If you are using Github, they provide an easy way to integrate this into your pull requests with Workflows.
- Inventory all of your service's dependencies as a Bill of Materials. Using a tool like LunaTrace will help you achieve this automatically.
Once you can continually build your project, the next step is to be able to continually deploy (a.k.a. CD, together they are the CI/CD pipeline).
- Document how the deployment process is handled. Understanding who has access to this process is critical. Unauthorized deployment of code can very easily lead to a bad security compromise.
Vulnerabilities are going to be discovered in your application. Whether they are found internally by a developer or externally by a security researcher in a bug bounty program. Establishing a culture around the reporting and management of vulnerabilities determines how quickly you can stop the bleeding of a potential compromise.
- Keep track of discovered vulnerabilities on a task board or with a vulnerability management tool such as LunaTrace.
- Incentivize developers to take ownership of remediating security vulnerabilities and recognize them for the work that they do outside their day-to-day feature development.
Once the Design and Implementation phases are complete for a project, it is important to review and verify what was actually developed. It is possible that requirements were lost in translation from design to implementation and if those requirements were business critical, as is the case with compliance requirements, then significant risk exists.
- Plan a meeting to have developers with the most experience with security review the design requirements and poke holes in the implementation to see if they were met. This can be considered a mini, in-house penetration test.
To make sure that vulnerabilities can't exist in code, writing tests is the best, most direct defense. Just like most tests however, getting complete coverage over all cases can be difficult. To make sure time spent writing security tests is done effectively, focus on the parts of your code that were identified in the Threat Assessment phase and write tests that address the following:
- Authentication - Does the user have permission to have access to some endpoint they shouldn't?
- Authorization - Can a user successfully perform some action through the API they shouldn't?
- Input Validation - If some malicious text is sent to the frontend or backend, is it blindly trusted? or is it sanitized?
- Encryption - If some data is sent from point A to point B, can someone in between see its contents when they shouldn't?
For examples of security driven unit tests, published Github Security Advisories will often include the pull request that was made in response to a vulnerability. For example the package
thenify had a critical vulnerability and was fixed and had security regression tests add in this commit.
- Write unit/integration tests that verify the existence of basic security controls. These might be proactively written to make sure fundamental compliance requirements are met or retroactively written in response to discovered vulnerabilities to prevent regressions.
Security testing comes in two forms: manual and automatic.
This will provide a point in time review of your project and help you fill in the gaps of your own security knowledge. These types of tests will not just give you a fishing rod, but also help you learn how to fish, so to speak. Do not treat findings from a manual audit as the end all, be all solution to your security as a company. Feed these findings back into your Design phase to better equip your own developers to make more secure decisions. Some recommended companies that will help you in this space are: NCC Group and Bishop Fox.
- Use your "Threat Assessment" as a treasure map to enable a pentest team to come in and pick apart your infrastructure.
This means installing a service into your CI/CD to raise alarms when security issues are found. The big question to ask when choosing an automatic testing service is: "What are the actual 'security issues' being looked for?". We have written about this before, but far too often what findings you end up with won't actually be at all meaningful to a developer. It is imperative that you value signal (meaningful findings) over noise (false positives) when it comes to automatic tools, because there are...a lot of tools. At risk of sounding like a pharmaceutical company, we give you the best advice in this space: "ask your security professional what is right for you". Here are some tools (not exhaustive) that we trust to continually deliver high signal-to-noise ratios: Github CodeQL, Detectify, LunaSec, SemGrep.
- Using your Threat Assessment as a guide, identify what services you care about the most to introduce automatic testing on. The initial rollout of a tool should be in "report only" mode for your security team to review. Over time, if you are receiving valuable, actionable results, then graduate this tool to start to take action on pull requests or generate tasks.
If/when a security breach happens, you will want to respond to these events quickly and decisively. It is essential that you are able to collect production logs from the possible compromise window. While certain attacks might be impossible to see in application logs, you may be able to see attempts at accessing different resources.
Any work that you have put into having a Secure Build and a Secure Deployment will pay dividends during an incident. Being able to quickly identify the issue from the logs, to writing a fix, and then rolling out a deployment could be the difference between a minor and a major exposure. Having a runbook available for how to handle these incidents will improve communication during an otherwise chaotic time.
- Make sure logs are being collected in production and enough information is being collected from critical services that will help during an investigation. Additionally, if your cloud provider provides access logs for its services, identify this feature and consider using it from your most critical services.
- Make sure your on-call rotation has a runbook for handing incident management.
As a quickly growing company, you will use any technology at your disposal to scale and grow. The side effect of this is that most likely you will not have "experts" of this technology and a possible misconfiguration or unpatched vulnerability is inevitable. Unless you have a dedicated team to constantly identify and patch outdated versions of software, you are unlikely to truly get ahead of this problem. This has become such a significant issue, that there have been government organizations and an executive order that have been made in response to this issue.
Even if you had a tool that inventories all of your software, the next step would be to identify when an update is needed. There may be updates to software that are simply bug fixes, but there will also be times that a fix for a critical vulnerability has been issued. For small teams that are rapidly growing, the last thing you will want to do is become a full time package update-er. An automated solution should tell you to update if, and only if, it is needed.
- Choose software/services that you use carefully and follow the recommendations outlined in "Secure Requirements".
- Consider using a tool like LunaTrace that will automatically keep an up-to-date inventory of software that you are using to understand when and where you need to focus your attention on updating software.
A project will hopefully have outlined how to handle data in the Security Requirements section of this post. If this was not translated into code during the Implementation phase, then hopefully this would have been caught during Verification. Even with the existence of these formalized processes, it will always be everyone's job to constantly watch for and raise awareness when data is not handled properly. Data, for most companies, is the reason they exist and make money. Compliance requirements ensure that a company will not go unpunished for incorrectly handling a user's data.
- Instill in your teams to be vigilant about how data is accessed and processed. Encourage them to take time to make sure "the right thing" is done with the data. If there is an ambiguity about how data should be handled, contract a security professional to provide guidance.
- Make sure legacy services are decommissioned properly and no data is being processed by them. As compliance requirements change for a company, old, forgotten services will be some of the first targets an attacker will set their sights on.
As your company rapidly grows it will be difficult for the security team to keep pace. The best advice we can offer is simple: "uphold the bottom line".
The terms "data breach", "cryptolocker", and "critical vulnerability" have flooded the news and have been very successful at distracting from the things that matter. Security companies make their money off of fear and in turn are not given an incentive to actually help calm any anxiety about security.
We believe that every company is capable of running their own successful security team. An important first step to making that happen is help companies dispel the snake oil that is far too often sold in the security space.
We hope this post helps you along your journey for taking action on security at your company. If you'd like to say thanks, we have a few ways that you can help us out below! :)
How you can help
- Install the LunaTrace GitHub App (for free!),
- Share this post with your friends and retweet it + follow us on Twitter.
- Star us on GitHub and read our docs,
- Subscribe to our newsletter (only a few emails per month, promise!),
- Come chat with us in our Slack Channel or you can send us an email too.