Regardless whether you’re creating and selling software or you’re just using it to run your daily operation, you are an IT company. Show me a business which doesn’t require technology as an essential element of its strategy and I’ll show you what you’re missing.
If you’ve been listening closely to the things taking place in the security industry you might have heard the following statement “security perimeter doesn’t exist anymore” thrown around like it’s nothing. Many of those who claim so in fact mean something else, which would be phrased more accurately as “security perimeter has shifted and the attack surface has changed due to wider adoption of cloud technologies and application of the DevOps culture”.
The reason for me bringing this up is that I’m seeing a lot of folks, ranging from security engineers, CTOs to even CISOs getting confused by that prior, blunt statement.
Security perimeter still exists and you still need protect the externally exposed resources the way you used to. You shouldn’t use that claim to justify your lack of capacity and not spending a sufficient amount of resources on the security of your externally facing infrastructure.
The first line of defense still matters. Yes, internal threat actors are a thing and shadow IT is prevalent, but cohorts of script kiddies, bots and newbie cyber-criminals are still probing your external infrastructure against common vulnerabilities. And they’re doing that all day long.
While for you to become a target for more advanced type of an attacker, you need to be doing something really well to become interesting enough for them to invest their time in breaking your security model. It’s not to say that it doesn’t happen for small companies, but likelihood of facing certain level of threat actors must be taken into consideration.
If you worked in a business role you likely know that resources company can spend on engineering are, and always will be limited. Security will always compete for resources with other aspects of business. While you’ll be unlikely to compete for resources with sales department as those units have separate budget, you will be splitting the budget with software engineers, QA engineers, DevOps engineers, IT OPS and alike. For that reason, you need to accept that your resources will be limited and keep in mind that while rarely you can do much (unless you’re a senior D/C-level exec) about the sum you’ll be able to spend, you are in control how efficient you are with your resources.
What I’m trying to say is that when you’re working as an infosec specialist at a company, you should never consider yourself from a perspective of us vs them. It’s in your interest to make infosec a part of engineering organization and work arm in arm with other engineering teams, because if you plug yourself into their discussions and workflows you can reap significant benefits from being able to interact with them. If you’re pulled into early discussions about SDLC, software architecture, infrastructure overhaul and you’re on good terms with other engineers you have a chance to influence the outcome of those discussions, embedding security into the process.
Each and every company wants to spend money wisely, meaning spend the least of it in a way that yields the highest benefits to the bottom line. You shouldn’t expect that one day you’ll be provided with enough resources to manage the security technical debt and clean up everything.
Especially in case of bootstrapped startups it’s hard to start thinking about security, performance and overall quality from the early days of your venture. The reality is that if you’re in an early stage of startup development you split your hair to improve your prototypes and make MVP out of it. That is fine and expected, but the moment your business starts being profitable with positive trend of it staying that way, you should rethink the priority of your security investments.
Now, getting to the point where you have a reasonable level of certainty about your startup’s future may take you a year or three or five, so don’t rush it. You don’t want to create a product all rugged and an engineering piece of art which is of not practical use. Business longevity comes first.
But if you’ve been profitable for a few years – take the word ‘profitable’ with a grain of salt. If you’re burning VCs money and you have a vision of an liquidation event but for now you’re spending more than your revenue would allow you to, then that is fine – having a solid position on the market and hundreds of paying customers should be a good marker to determine your readiness to switch gears a little bit and start investing in your organization’s safety.
For many startups, there happens to be an ideal moment when you can take your shots.
At a certain level of startup’s growth you get to the point where you can’t continue with the technical debt you accrued while building the MVP, at the same time your business is stable enough that you can slow down the growth of the product and invest in architecture overhaul.
That’s the sweet spot to introduce professional security practices into the process. You’re tearing things piece by piece and remodeling it to make it ready for the growth of your business, and each part you refactor should now get injected with quality/security/performance/resilience practices. At this point, it’s as if you were embedding your processes into the business from the day 0, but it’s even better than that – you now have semi-mature infrastructure, tooling and competent engineering team who can fit security much better than it would have when the whole product was sitting on a paper in a design phase.
It’s uncommon to be capable of pushing the business to give you resources to refactor a piece of application just to address the security technical debt. But in that peak of startup’s growth, right before accelerated-growth phase, engineering is provided a significant budget to invest in technical debt, at the same time enabling you to multiply your potential impact, because your changes will take up an insignificant sum of it all.
For that reason while running security operations for organizations at any level of its maturity, you must leave wishful thinking aside and start to strategize on how you can embed security practices in the work of other departments. The perfect moment when all eyes are on security won’t happen – unless you’ve been compromised already and your executive team has strong incentives to do something about it.
Whenever you see a new project or an overhaul of an old project, that’s the real perfect time for you to focus on building the security into it. That’s the moment when you should drop your other tasks and focus solely on the opportunity at hand, because once that’s gone it’s gone and you’ll need to either way a long time for next refactoring or fight for the dedicated budget to improve its security – and that’s never easy, no matter how mature you think your organization is.
After all, we all want to get things done with as little friction as possible and for that reason we need to compromise on the ideal, to achieve the general efficacy of IT security operations.
Regardless of current trends, my style will remain to be such that human education comes first, perimeter safety comes right after and only if I know I have the viable level of safety there I move to securing the internal assets. Until then, I won’t realistically bother with shadow IT, APTs and internal threat actors, ’cause changing ones strategy to adapt to current trends and abandoning common sense is nothing but a security theater.
Triage, prioritize, execute.
Comments