• When should my startup prioritize infosec?

    If you imagine your organization as a sea-faring vessel, infosec’s goal is to ensure the boat can survive krakens or canon-wielding pirates and successfully complete its journey. If you ignore the existence of sea terrors, you may not make it to your destination unless Poseidon grants you merciful passage. If you prioritize defense above your vessel’s mission, you will find yourself aboard a battleship that is entirely inadequate for transporting revenue-generating cargo. — On YOLOsec and FOMOsec, Kelly Shortridge

    Startups are all about focusing on the right thing at the right time. Juggling everything through the fog of product development, managing your runway, and growing a team are tough on their own. Unless it’s a primary piece of your product offering1, security is rarely prioritized in the early days of a startup. Contemporary startups have the benefit of the accumulation of best practices becoming more commonplace and accessible: appsec best practices get caught in code reviews, infrastructure providers bias toward secure defaults, engineers are accustomed to using things like password managers and MFA apps. However, beyond that, founders in search of product-market-fit do not have the cycles to focus on infosec. It’s a type of technical debt that is accrued while focus is elsewhere.

    As your traction begins to grow, paying down technical debt becomes a recurring focus for the team. This typically takes the form of application, infrastructure, and ops related debt. Preventing the CEO from accidentally deleting the production database is a more immediate threat than a targeted attack. Improving your processes to prevent shooting yourself in the foot will pay immediate dividends. Solving your startup’s problems around self-incurred outages and data loss are more pressing than infosec.

    There is no positive benefit when it comes to security — the best outcome you can expect and actually aim to get is a reduction of negative impact. Your product or customer experience is not directly improved by an increased security posture. However, the amount of downside is unknown and potentially large. This is what will start keeping the founders up at night. Peace of mind. It all changes when there’s now something at stake. Reputation. Customer trust. Reliability. Anything that’ll erode that hard earned product market fit. Any bad press that’ll reduce the slope of your week over week growth.

    This is the right time a startup should start prioritizing infosec.

    The Startup Curve Overlayed with paying down tech debt and when to start thinkinga bout infosec

    The Startup Curve - Overlayed with paying down tech debt and when to start thinking about infosec

    For all the fear-mongering related to security that’s out there, even for well-established companies, security’s priority with respect to product can be a tricky thing to pin down. Is it just another sign off like legal review? Was it just bolted on because an enterprise sale necessitated it? The earlier your startup weaves infosec into the engineering culture, the longer head start you have in paying down security related technical debt. The dividends you get from this yields a resilient engineering organization which treats security as a partner in building the product and not an impediment.

    Further Reading

    1 Some other scenarios where security is an early priority for a startup. 1) Product mandated security considerations: it’s in the value prop of the product, mandated by a vendor (i.e. using the GMail API requires an external security audit); 2) Externally mandated security considerations: Government or industry regulatory considerations; product penalties if you are non-formant (i.e. amount of loan origination that can be a penalty if your banking startup is fails external security audits); 3) Customer mandated considerations: AWS GovCloud, SOC2, etc — it’s forced by the need to acquire specific customers and/or drive sales.

  • Do The Basics First - What To Check Before Launching on AWS

    How do engineers make the seemingly-obvious mistake of opening their infrastructure to the world? Usually, with the best of intentions. When you’re building out your infrastructure, you tend to accept the first set of permissions that makes things “just work”. I just need this lambda to talk to that database. I just need to read files from that bucket. And quickly.

    Yes, maybe now your Lambda is a bit over-provisioned and it could overwrite the data in that S3 bucket, but you wrote the Lambda, and it doesn’t do that. All good. Except when it isn’t. Except when you opened some resource to everyone with an AWS account, instead of everyone in your AWS account. Security misconfigurations aren’t like the other bugs in your application. They don’t break functionality, and usually, customers don’t notice. You probably don’t have an integration test that fails if it can successfully publish to your SNS topic from the wrong AWS account.

    Being a responsible engineer, you set out to rectify the problem. You peruse blog posts and look up standards. You determine that you need to enforce least privilege, follow the swiss cheese model, and enable network flow logs. Your ship date slips, a lot. It’s easy to go overboard.

    What’s missing is a prioritized list of basic checks and settings. Just like launching without every feature built, you don’t need every security principle fulfilled to the highest level. With that in mind, here’s our short list for when you’re starting out:

    1. Secure your perimeter. You should know, off the top of your head, every resource that is public. It’s probably a short list. A load balancer, an api gateway, or an EC2 instance. Maybe an S3 bucket, or maybe a CDN in front of one. If it’s not a short list, determine how to shorten it. Use this list to conduct a quick audit of your resources. Is it public? It had better be on the list. Otherwise, make sure it’s private.

    2. Secure your credentials. Know which humans have admin access. Use an IAM Group for this. It should be trivial to look up this information. Ensure they all use multi-factor authentication. Know which third parties you’ve given credentials to. Remove the ones you no longer use. Delete any user API credentials that are not needed.

    3. Turn on multi-region CloudTrail. Start building your audit log. You might not need it anytime soon, but someday you’ll be glad you had it enabled.

    These steps will largely keep you from falling victim to automated sweeps for infrastructure mistakes. As you grow your team and accumulate data from running your product, your needs will change. The threats will change. You will read about defense-in-depth, and about the perils of a hard exterior shell with a gooey center, and the importance of intrusion detection and auditing. There will be encryption-at-rest, log verification, and IAM access analysis. All of these things are important, but what is often unstated is that they only matter if you have done the basics. Security features must be layered on a foundation, or else they will only end up causing headaches for little benefit. Do the basics first.

    Gold Fig can help with the basics, and beyond! Talk to us about getting an assessment of the next steps to take, tailored to the stage of your company.

  • Our Philosophy

    No one doubts that security is important for cloud infrastructure. The potential for harm to your business, your customers, and your reputation is real, and that potential increases with your business’ success. And yet, customers will not reward you for weeks spent locking each credential down to the barest minimum of permissions. You will not increase your site traffic numbers by meticulously applying network segmentation to your cloud environment. Your product doesn’t become more useful if everyone on your team has MFA enabled.

    So, should you do these things? Well, it depends (except for MFA: do that). It depends on who you are. It depends on what you have at stake. And it depends on what the threat is. Finding and fixing what really matters to stay secure is not one-size-fits-all.

    Who Are You? Are you a single developer, or small shop? Broad permissions for you and your team are probably ok. These should still be applied at a group level, rather than to an individual, but you probably don’t need to think too hard about limits yet.

    On the other hand, if you don’t personally know everyone with access to your account, it’s past time to start applying some stricter grouping and permissioning.

    What do you have at stake? Do you avoid collecting Personally Identifying Information? Do you avoid hosting content uploaded by users? You may not need a full audit trail for every data access in your system.

    On the other hand, if you host sensitive information, verifiable logging starts to look like a pretty good idea. Effort spent ensuring your data is encrypted at every stage is probably worth it.

    What is the threat? Are you a smaller or mostly unknown business? Your biggest risk is probably from automated scans and phishing attacks. Keep your buckets and credentials private, keep your firewall locked down, and enable multi-factor authentication.

    On the other hand, if you are worried about targeted attacks, you’ll need more serious measures. Intrusion detection and limiting blast radius become requirements, rather than distractions.

    At Gold Fig, we think it’s important to understand your situation before making a security assessment. Presenting a red wall of security failures guarantees that nothing will be addressed. Prioritization matters. Prioritization means more than just attaching a severity score to each security check in a scan. Once you’ve closed gaping holes, ROI becomes a major driver in the discussion. Meaningful security improvements come from matching a company’s current stage to a handful of immediate steps to make. Peace of mind for your infrastructure team comes from building this process into your routine.

    Want help prioritizing your security projects? Talk to us!

subscribe via RSS