Disclaimer: The recent SVB debacle has largely influenced this list. Publishing after March 9, 2023 has reshaped my perspective of the cybersecurity landscape.
So, without further ado – considering we are already approaching Q2 – here’s what I think should be top of mind for cybersecurity professionals for the remainder of 2023.
#3 Cloud Strategy
Making a repeat appearance in my top three is cloud strategy. The pandemic compelled nearly every organization to force-multiply implementing their half-baked cloud strategies. Even though it’s been over two years, most still have really, really messed up cloud environments. And, because they haven’t retroactively evaluated and secured their cloud operations, there are massive cyber security issues bubbling up from inside of the cloud and erupting all over unsuspecting businesses and their customers.
There are so many examples of cloud vulnerabilities being exploited via multiple tactics. Hacks through vulnerable code pipelines, or through leaking of credentials inside github accounts that led to leaked credentials inside of cloud environments, or phishing attacks that led to compromised credentials directly of cloud environments, or people who have stolen tokens from infrastructure as code and identity and access management permission misconfigurations inside of AWS environments. Each had major impacts and led to intellectual property being stolen from those organizations.
Cloud is massive. And many security teams do not understand it well enough to protect it. Moreso, they don’t understand the tools that AWS, Microsoft, and Google have created to help audit and monitor your cloud infrastructure. As a result of poor cloud architecture and cloud control, this will likely be the primary threat vector for cybercriminals, and hackers are going to be successful with attacks like ransomware, crypto mining, and theft of source code in the cloud environment.
Recommendations
Implement the same common NIST or CIS controls that we have been for on-prem corporate infrastructures for the past 20 years. Back to the basics:
- Strong password protocols – self-explanatory. Passwords should be hard to remember.
- Good identity and access management – Make sure the right people have access at the right levels to the cloud infrastructure pieces that they need on your development pipelines. Reduce the amount of people that have root level access on your AWS environment. Utilizing concepts such as a “zero trust architecture” (not a tool) and infrastructure as code means that you can have a good solid CICD process from code creation to code deployment. You do not want people to have direct remote access to your AWS environments.
- Proper network segmentation – segment each of your environments/business structures, either inside of your VPCs, inside of AWS, or have logically separated cloud organizations for DEV PROD STAGE, …
- Conduct vulnerability assessments and penetration tests in the cloud – Actively scan for secrets inside of your code.
#2 API and Software Supply Chain
Software engineering is thriving because of API integrations and open source repositories and coding practices. Sadly, this surge of resources is also leading to a massive increase in attacks.
Just a few years ago, APIs were a function of software engineering and digital innovation teams, not traditional IT or cybersecurity teams. To provide awesome software development engineering, APIs have to integrate in and out of products. But our ability to audit, evaluate, test against, and provide security controls for those APIs did not keep up. As a result, APIs have led to data breaches and disclosures of sensitive information, because the APIs weren’t configured appropriately. For example, in one case the developers weren’t looking for authentication tokens when requesting certain specific pieces of information. In another, the developers were not providing authentication when APIs were being used to push information to a company or a software package. Each omission led to a breach, and attackers are now actively looking to exploit the shortcomings in API security. Enterprises will need to keep up.
People are creating programming languages, content management systems, all types of platforms in frameworks that are new and innovative and work really, really well because of these publicly available integrations and codes. How wonderful! However, it’s important to remember that many of these frameworks are developed and maintained by the community and have no formal audit process, outside of the crowdsourced community in which it is developed. This means that you could rapidly be implementing frameworks that haven’t been adequately evaluated for their potential security vulnerabilities.
The speed of the life cycle from creation/ideation into the production environment is creating this kind of vacuum between untested code and untested API’s that lead to attack surface issues inside of the software development process. We began to see the start of this back in April 2014 with the Heartbleed bug, a large vulnerability in the fundamental trust layer of our cryptographic systems based on an open source project. This hasn’t let up since then, and we see this being actioned on by hackers in everything from WordPress, its plugins, and even with the semi-popularized Log4Shell vulnerabilities in Java.
Recommendations
APIs and open source coding are evolving so rapidly that the industry has not codified what the standards should be. So, CSOs and other security professionals are left to their own devices. While this may breed innovation in some industries, in cyber security it creates an opportunity for attacks while we collectively research best practices before investing and implementing a security strategy.
- In the meantime: create a software bill of materials! We may not have solidified best practices, but we all acknowledge that knowing the software that’s being used in our environment is critically important.
I’ve worked in organizations with 250,000 employees and tons of custom code, and it’s monumentally challenging for an organization at that level. The bigger the organization, the more custom the software, the harder to get to the bill of materials, so start early!
- Apply your software development lifecycle practices for security, not just to your code base, but also to your APIs. You can follow the OWASP best practices for API security.
Enforce proper authentication on your APIs, data management/data filtering on the data requests that come in and go out of your APIs, data segmentation on the permissiveness that those APIs have to access information inside of your environment, etc.
Conduct penetration testing. There are tons of pen tests and vulnerability scanning tools that specifically target APIs. Use them.
- Leverage a third party to help you. This is a rare suggestion from me, especially as this is still an emerging part of the industry. But, because it is so gnarly and there is so little data, I absolutely recommend reaching out to an API security specific organization to help make sure your setup is solid.
At a minimum, I would look for a provider who can evaluate your API’s across the broad spectrum of your applications, not just “point in time” like many API Gateways and WAF’s currently do. Ensure they are mimicking attack techniques of utilizing your API’s in a logical fashion that looks for context to perpetuate the attack, instead of a linear model that leverages only legacy web based vulnerabilities like XSS and SQLi.
Finally, leverage someone who can help you inventory all your API’s, not just the ones you know about, so you can find attack surfaces before hackers do.
#1 Risk Management
Risk management has thrust itself to the forefront of the cybersecurity landscape. A failure of appropriate risk management practices might end up being an actual realized threat in 2023.
The Silicon Valley Bank (SVB) calamity should have caused nearly everyone in the tech industry – and their customers – to (re)evaluate the risk associated with each of their third party vendors. To my knowledge, no one had any suspicions of SVB going under before March 9. So, how could we prepare for this, and how does this manifest into 2023?
Let’s talk hypothetically:
As an enterprise organization, you probably have a mix of low risk, high profile companies providing services for you, but you also probably have some high risk, low profile companies, too. (This is why entire third party risk management (TPRM) teams exist in big enterprises.) Overtime, an excellent tech startup with funding from one source (a high risk company) became very crucial to your operations or security posture. Then, out of nowhere the company ceased to exist because of no fault of their own – like their bank going under. What do you do? You have a huge gap without that company. Without a proper plan, the dominoes will fall.
There are often significant benefits to working with a high risk company, so it is always important to weigh risk vs reward.
Recommendations
Develop a strong TPRM program. Understand your organizations and the companies that are providing you services, and how critical they are to your business operations. Some questions to get you started:
About your vendors:
- Do they provide critical services?
- Do you understand where their funding is coming from? How secure do you feel in that funding?
- Do you have disaster recovery plans for if that critical asset or critical software technology becomes unavailable to your operational teams?
- Do you have a resiliency plan?
- Do you have suppliers ranked from a high risk to a low risk?
About your own organization:
- Where do we put our money?
- What do the covenants allow us to do? Not allow us to do?
- Do I understand what our business risks are?
- How do I convey that business risk when I get asked, “how can you assure me what your risk exposure is?”
- Do we have a resiliency plan? Can I explain it?
- Do I have suppliers ranked from a high risk to a low risk?
- Am I in touch with my CEO?
I recently made a video with our CEO, Matt Eberhart, about the SVB fallout. You can check it out here.
Conclusion
The truth is no one knows what is going to happen in the future, even as soon as next week. The pandemic, the SVB situation, and, well, regular disruptions to our modus operandi have made that very clear. But that is why I love my job, this industry, and my life. Uncertainty and fighting the good fight are what make cybersecurity exciting. We have to stick together. We’re all in the same trench, the same foxhole, together, defending enterprises, and doing the best we can with what we do know. What I can tell you is that a good “battle buddy” is the key to success in our mission. If you need a battle buddy, reach out to me. I’ll fight the fight with you.
