9 Steps to Create a Security Program on a Budget

In today’s threat landscape, a good security posture is needed to protect your business and your customers from potential cyberattacks. But when you’re on a shoestring budget, that’s easier said than done. So how can you get a good security posture without having to dedicate much of your already limited resources?

Here are a few points to consider:

1. Hiring a security team: Who you need, and when.

You don't need a dedicated hire right away. Instead, nominate someone inside your organisation to have the responsibility for security until a full-time hire is necessary. This should be a technical person who is responsible for setting standards and ultimately policies for collaborators as well as guidelines to help secure your company’s most sensitive data. You may find this person already in your IT or Engineering departments. When that basic set of responsibilities becomes too difficult to maintain in addition to a full-time technical role, it’s time to hire a standalone resource. Until then, security is everyone’s responsibility.

2. Set policies: They can save your life.

Setting policies like acceptable use, information security, incident response, and software development is critical to every security program. They aren't just lists of rules; they should be how-to guides that keep your security program organised and collaborators aligned on expectations. Not only will such policies help with compliance requirements and prospects, but it will also provide clear guidelines and instructions for how all operations – from worker/workforce passwords to software development – are managed with security in mind. Keeping policies up-to-date and ensuring they include clear guidelines can be a lifesaver in a crisis. Numerous policy templates are available online, but don't just copy them: if a written policy does not fit how your organisation does business, it will be ignored, and that can be worse than not having a policy at all.

3. Know your weaknesses: Establish a baseline for risk.

Much of the work in security comes down to risk management: identifying threats and prioritising limited resources to deploy mitigations. Create an initial posture evaluation to identify your potential risk areas. Then, understand the scope of the data you have, infrastructure, and business processes.

Establish a baseline with a full risk assessment by bringing in a technical moderator (they could be internal) who understands the threats relevant to your business to evaluate the extent of risk mitigations for each major component of that scope. The results should allow you to prioritise your mitigation projects based on residual risk, which consists of inherent risk and operational controls. From there, establish a frequency for these risk assessments, usually on an annual basis.

4. Nail the basics: Maintain a good security hygiene.

Make sure basic security hygiene is part of everything you do (and serves as the fundamentals upon which your policies are built!) Ensure you have strong endpoint (for example, antivirus, hard drive encryption) and infrastructure security (such as open source tools like Security Monkey) to help set secure configurations and subsequently audit against best practices. Strong access management controls are essential from the start, and be sure to enable multi-factor authentication (MFA) for everything.

Build these practices in the cloud where possible: this will enable you to leverage your cloud providers’ security investments for your own organisation and also help with your security budget. Don’t rely exclusively on them for your security, though – understand where the responsibility of the cloud provider ends, and where yours begins. Good hygiene should also be maintained by undertaking exercises to reinforce and reassure hygiene, such as awareness training and testing. In doing so, not only do you strengthen security DNA at little or no cost, but you avoid large corrections which can eat into your budget.

5. All software has bugs part I: Managing your own code.

All software has bugs, but not all bugs are created equal. When it comes to managing your own code security on a budget, the goal should be to build as secure as possible and then use vulnerability management to pick up the stuff that gets through. Encourage your engineers to leverage the OWASP Top 10, for example, to help them avoid common mistakes companies make developing software, and encourage secure coding education for software engineers to ensure low hanging fruit doesn’t become an issue. Then, leverage resources such as open source or free static code analysis, secure frameworks, peer code reviews, and provide guidelines for how people can contact you about bugs they’ve found. All of these guidelines should be a part of your policies as well.

6. All software has bugs part II: Get started in vulnerability management.

When it comes to third party software, you can get started with free vulnerability scanners. But make sure you use one that has both a good reputation (check out other customers, references, etc.) and is being maintained. Subscribe to open source and, later, vendor security notification services for the critical components of your infrastructure: Every responsible software vendor has an email newsletter you can subscribe to, or a webpage you can go to, for the latest security notices. This can be more effectively managed by tying notices into a ticketing system, like Jira, so each new alert creates a ticket someone has to review.

Combine this with policies establishing the SLA for patching various classes of vulnerability, and you have the beginnings of a vulnerability management program equal to that of most enterprises. Suggested SLAs for patching:

1. Critical bugs: Should be fixed or patched in 24 hours
2. High risk bugs: Should be fixed or patched in 48 hours
3. Medium risk bugs: Should be fixed or patched within 30 to 60 days
4. Low risk bugs: Should be fixed or patched within six months

7. All software has bugs part III: Be open to and participate in vulnerability disclosure.

First and foremost you should make sure you have solid processes for handling vulnerabilities in your own code. Fixing third-party vulnerabilities is a matter of prioritising the right patches or work-arounds from vendors. However, vulnerability disclosure means finding security bugs in your products or code. This is a good thing, but only if you can take advantage of it.

A responsible, well positioned security company welcomes all useful ethical forms of disclosure, coordinates with the researcher disclosing the bug and most importantly has the right processes to feed the issue into engineering so that it can be fixed. Many companies run a bug bounty program to facilitate this and to triage incoming issues, however both are benefits that can be layered on gradually as your program matures. The same goes for rewarding researchers for bugs, ultimately if you want serious researchers to find important issues, you will need to reward them. Free programs can be useful to start, but they rarely attract the best researchers. Looking at other bug bounty pages for companies of a similar size and in a similar industry can be a good way to benchmark your own program.

Be aware that a researcher will almost always want to publicly disclose an interesting vulnerability. The best approach is to coordinate this with the researcher so that it comes out after all the issues have been resolved and when users and products are protected. This is seen as a net positive and companies that behave in this way have the healthiest security programs.

8. Find the best partners: Use software with strong security programs.

Your early software selection choices can also have a significant impact on your security program. Choose vendors with strong security practices for everything from email to storage; they’re key to running a secure operation at a low cost, tend to be sticky and will get more expensive to replace with increased adoption – so choose wisely at this early stage. For example, choosing Chromebooks over Windows at the start gets you significant security benefits for free (not to mention, you’re avoiding the cost of endpoint security like antivirus software and patch management, which can become significant budget line items as you scale). Additionally, selecting a vendor with strong security posture helps instill confidence in prospective customers.

9. Don’t forget about compliance: Save yourself time by baking compliance in early.

Compliance is an aspect of security operations that cannot be thought about too early, and there is enough depth here to fill out its own full post. The biggest blocker to early compliance is fear: But while often perceived as such, compliance is not, in fact, a scary monster.

Compliance early is both good for your business long term and can actually be your friend by acting as a platform to accomplish many of the items mentioned above. Every industry has its own set of compliance requirements: begin with smaller initiatives that allow you to self-certify, such as PCI or CSA STAR. If you implement these requirements early on, getting additional certifications will be much easier and far cheaper in the long run.

In Conclusion

Again, it should be understood that security is the whole organisation’s responsibility — from your newest intern to CEO — and you’re only as secure as your weakest link. As your organisation continues to grow, invest in capabilities like security monitoring and take advantage of virtual CISOs as an interim solution until you’ve reached a point where you need a dedicated security leader. Understanding how to prioritise your resources, what building blocks you should focus on early, and when to invest more heavily in your program can set your organisation up for success.

Visit Okta’s Trust Page for information on how Okta approaches system statuses, security, and compliance.