DevSecOps and other security buzzwords that will make the endangered list in 2024

This all started when Tim Tomes asked for DevSecOps resources on LinkedIn:

I’ve never been a big proponent of the term DevSecOps. I believe the “Sec” is silent and that DevOps should already have security baked in. That’s a post for another time though. As I thought about it I hadn’t really heard the term in a while. Some of that may have to do with being in a broader space and no longer focused on just application security. I decided to hit up Google Trends to see what it had to say about the term DevSecOps.

Search trend for “devsecops” via Google Trends

Using ChatGPT I asked for DevSecOps resources. It provided some Microsoft, GitHub, GitLab, and a DevSecOps University. The best one is probably the GitHub project Awesome DevSecOps but that hasn’t been updated in three years. The other resources were stood up between 2022 and 2023. AI has probably over taken a lot of other conversations on the internet in the last year.

I looked at two other buzzwords Digital Transformation and Zero Trust. Both had similar trends to DevSecOps.

Search trend for “Digital Transformation” via Google Trends

Search trend for “Zero Trust” via Google Trends

I suspect AI is definitely impacting and we’re starting to see less interest in the other buzzwords.

Search trend for “AI” via Google Trends

I’d be okay if the term DevSecOps went away or was at least less used. I believe security is something that’s already baked in when done right. We don’t need to add our own flair to terms people use in other industries. I expect AI will start to ooze into buzzwords and continue to overtake buzzwords that have emerged over the last several years.

Leave your thoughts in the comment section below on other buzzwords to add to the endangered list.

This post first appeared on Exploring Information Security.

Cybersecurity Predictions for 2024

Here are my predictions for 2024.

Exploring Information Security relaunches

I will be launching Exploring Information Security as a company in 2024. I may or may not have some insider information. I’m in a bit of a career transition and I have the opportunity to try turning this idea into a company. More details to come.

New buzzwords

I asked ChatGPT for some 2024 buzzwords. A couple of my favorites include:

Cyber Resilience: Focusing on an organization's ability to continuously deliver the intended outcome despite adverse cyber events.

Regulatory Compliance Tech: As regulations around data privacy and cybersecurity tighten, technologies and solutions to aid in compliance will be crucial.

Cyber resilience is an interesting one because I’ve worked in the Incident Response space for the last several months and the difference in backup plans for a ransomware attack varies by company in the small to medium business market. Some have a plans on how to continue to operate while others have zero ability to operate while down. This is basic disaster recovery planning and it doesn’t have to be malware it could be a natural disaster. I expect ransomware will become more of a topic in disaster recovery planning.

ChatGPT gave me plenty of AI buzzwords and I think that’s what we’ll see more of in 2024. AI will be thrown in everything even more than it was before. I imagine some form of AI defense or AI security will emerge as well because it’s a bit of a hot topic.

More breaches reported earlier and then updated later

As I recently wrote last week, Okta and 23andMe A New Public Relations Tactic in Disclosure? I suspect companies will report breaches sooner with limited information and then update later. First impressions are a hard thing to overcome. This is something companies will look to exploit as they try to control the public relations narrative.

On the less cynical side the new SEC incident disclosure rules are in effect and companies have less time to report on a breach. This could mean companies are reporting with less information and then need to update later. We’ve already seen a ransomware gang try to use this new disclosure rule to their advantage by filing a complain with the SEC because the company refused to negotiate.

Social engineering continues to make a comeback

With groups like Scattered Spider and LAPSUS$ emerging over the last couple of years I expect there to be more social engineering based attacks to get into an organization. We saw it in the second half of this past year with the MGM and Caesar and Okta hacks. The Verizon Data Breach Investigation report highlights the human element every year. We are the most susceptible systems to an organization. Everyone can be manipulated in some way.

Finally, AI will start to have a large impact on the workforce

AI is here to stay and I can tell you from experience that it is very useful. It will change society significantly over the next 10 years. Next year is going to be a big year. 70-80% of this site is built with the help of AI. I would not have been able to put up as much content without it. It’s been a great learning opportunity.

Development and documentation based professionals will be impacted the most this year. People not use it will put out more work than their co-workers. People that don’t will be let go because they won’t be needed. Developers are already using it to start code and build unit tests. GRC folks can write 10 policies in a matter of just a few hours. I did it for a company last year. Whatever field you’re in, I’d recommend starting to get familiar with it now because the next generation of professionals are already there.

What are your predictions for 2024? Leave a comment below.

This blog post first appeared on Exploring Information Security.

Okta and 23andMe a new public relations tactic in disclosure?

I’m starting to wonder if we’re going to see a new tactic for US based companies where they report an initial breach and then report the full extent of the breach later at a more opportune time.

We’ve already seen this whether intentionally or unintentionally with the breaches of Okta and 23andMe. Both reported a small amount of their use base was impacted. Then several weeks later came out and reported it as much larger. It would be an interesting tactic especially since the new SEC rules are now in place as of December 15, 2023, requiring companies to report a material cybersecurity incident within four business days.

Public Relations (PR) departments have always looked for ways to limit the impact of a breach hitting the news wire. They’ll often release bad news on holidays or around other major events. Caesars did while the MGM breach was hot in the news cycle. They released their own breach by the same threat actor. A couple months removed and most people only remember the MGM breach.

I’m in the security news bubble so it’s hard to say if this tactic is working. Okta is a company that’s in the security space so most people outside of security don’t care about it. 23andMe is a DNA testing service for health and ancestry discovery and it’s still early to determine the effectiveness of their PR mitigation.

Looking at it from the companies perspective, we have asked for more transparency from companies on breaches. That could be what we’re getting here. They’re providing additional information for disclosure purposes and education purposes. Being honest and conscientious is not always reward in the media. There are companies who will do the right thing but are others who will not.

I think it is a new tactic and I’ll be curious to see if more companies start trying the strategy of releasing an initial compromised and then coming back later to, “correct” it. Especially, in the case of 23andMe who has decided to update their Terms of Service to include litigation protection for themselves. It just looks bad.

This blog post first appeared on Exploring Information Security.

Log4Shell, is it really an issue at this point?

I thought reading the Veracode State of Log4j Vulnerabilites: How Much Did Log4Shell Change? by Chris Eng would be a bit of FUD (fear, uncertainty, and doubt). I was pleased to see that it wasn’t. They provided some great numbers on Log4J and remediation efforts. I was also happy to see them recognize that developers fix vulnerabilities when alerted about them quickly. This is something I talk about a lot in my presentations and with security folks. Developers want to get this right and having right approach and empathy with vulnerability management will get them to buy into these efforts.

The next line though says that the data contradicts the developers response because there is so much Log4j out there. Reviewing the CVEs in the article most of the remaining Log4J is in other packages. This is a problem with packages and open source. A package can be buried in another package. This was highlighted several years ago with the left-pad incident. A disgruntled developer removed a small bit of code that added a left-pad to the side of a website from NPM. It took down thousands of website because that line of code was buried in other packages.

This is why security needs to take a balanced approach to vulnerabilities and not lean only on severity rating. We need to be building proof of concepts. The reason why Log4j was such a massive thing was because it was buried in other packages. While it might be in another package it might not be used or accessible by attacker. In the case that it was it’s important to understand what it gives an attacker.

This is where the balance comes in for security. Just because the vulnerability is an 8-10 severity doesn’t mean that’s it’s actual severity in each environment. If it’s note exploitable it’s more like a 1-3 severity. Which moves it down the priority list of vulnerabilities of which there are usually hundreds of thousands.

Don’t get me wrong you want to get those vulnerabilities addressed but the timeline for getting them addressed changes. When I was leading the effort for Log4j remediation in our environment we used the pentest team to find what was exploitable externally. After remediating those vulnerabilities we looked internally. Most vulnerabilities could be patch but internal couldn’t be updated immediately and required a larger upgrade to accomplish. This is where we established timelines with those teams to get the vulnerability remediated because we knew what needed addressing immediately and what could take more time Just a blanket patch it all now would interrupt business processes, projects, and create hard feelings.

It’s good to note that Log4j is still out there and probably extremely important for companies to patch. Security needs to identify how much of it is actually vulnerable and work with other departments and teams to figure out the best timeline. Development teams need to be focused on more immediate issues such as the Atlassian server having a vulnerability or the latest malicious NPM package. Those are more important than a two-year old vulnerability that may or may not be exploitable. If it is exploitable go patch now!

Chucking vulnerabilities over a wall to developers is never a good strategy and will waste a lot of time and effort and degrade trust between departments.

If you are in need of consulting services on vulnerability manager or application security click the contact button below and reach out. I’m happy to have a conversation about your struggles and identify how I can best help.

This blog post first appear on Exploring Information Security.