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.

Leveraging the security mindset of others

I am over six months into my new role as a senior software security engineer. My role has me embedded with the development team. I go to meetings and interact with the team on a day-to-day basis. My desk is in there area. I go to lunch and conferences with them. As I’ve gotten more familiar with the environment and team, my task list has started to grow.

One of my co-workers noticed this and while leaving a meeting the other day asked if security had plans to hire another security person. I responded that I thought they might in the future, but that I wasn’t counting on it. It took two years to fill my role. With the current “talent shortage” it may take another two years to fill a similar role.

My strategy for getting security into the software development life cycle is to leverage the skills and knowledge of the developers. They are really smart people, so I put a focus on improving the security mindset of the developers. In meetings, I let them to talk through security issues and find their own solution. Just me being there the developers know that security needs to be taken seriously. For the most part they choose the right path.

I also recognize when security issues are identified and addressed by the development team without my involvement. The development team is already doing a lot of good things from a security perspective. By recognizing that in a meeting or one-on-one I am amplifying and encouraging that type of behavior. Using that strategy, I’ve started to see improvements in the development team in regards to security. The other person I was discussing this with agreed. They were seeing more focus being made on security.

Do we need more people in security? I don't know. What I do know is that the security industry is having a tough time finding the right people. Maybe we need a different strategy. I think that strategy should include leveraging the security mindset of others. I've had some encouraging results so far. It will be interesting evaluate the strategy a year from now.

This post first appeared on Exploring Information Security.

Rethinking the security team

What if security teams placed their people into each department, instead of their own?

This is the position I currently find myself in. Four out of five days I sit with the development team with the goal of improving security in the software development life cycle (SDLC). It is going really well. It's going so well in fact that I've started to wonder why we don't do this more?

There would still be a security operations center and some other roles, like pentesters, working in a security space, but why not place a person in network or the server team?

Being in the room with the developers I'm able to build strong relationships within the team. I'm a security resource for them to bounce ideas off of and gain clarification on various security ideas and concepts. This makes things tremendously easier when I look to establish security processes and practices for the dev team. They see me daily and know that security is a priority. They also know that I see their successes and their struggles and that my goal is to help them be successful.

I believe this can apply to other departments. If security is involved the day-to-day operations of a team we are seen more as a resource instead of someone holding them accountable. We are still holding them accountable. The difference is that they can ask us questions. Why are we doing it this way and not this way? I'm finding people are much more amenable to security initiatives when we can explain why it's important and it benefits them.

This post first appeared on Exploring Information Security.

Information security podcast review

There are a lot of good information security related podcasts out there. Here are the ones I listen to and my impressions of the show. In no particular order.

PVC Security Podcast - FULL DISCLOSURE: I produce this show, would appreciate any feedback you have for the show positive or negative.

I love the passion and fun Paul and Ed bring to the show. They speak their mind and have some fun doing it. I take the quality of a show very seriously both from a technical and non-technical standpoint and I was happy to find that Paul and I share a lot of those same philosophies in the production of an audio show. We’re only 10 episodes in, so we’re still figuring some things out. When we created the podcast we decided that it wouldn’t cover news topics (though I did make them cover Sony) like several of the other podcast. Instead we wanted to focus on how to become a better information security professional and how to facilitate an improved security culture within an organization.

Security Weekly - This was one of the first podcast I was able to find on information security and it’s easily one of the top podcasts in the infosec community. It can get a little vulgar and can get a little off track, but the co-hosts are very knowledgeable and entertaining. It can get a little long, usually running 60-90 minutes, but that includes an interview, a demo and a news segment. Of the three segments the interviews are the best. I have gotten more information and ideas and tools out of this podcast than any other podcast I’ve listened to.

Down the Security Rabbithole - If you’re into enterprise security and want a more top level view of information security this is the podcast for you. They cover topics from an executive level as well as dive into the legal aspects of information security. They do cover news topics but do it from a much broader viewpoint. My only gripe with the show is that the audio quality can be lacking at times. The main issue being co-hosts being at different volume levels throughout the show. The audio quality seems to be getting better though

Risky Business - The best information security podcast out there. Patrick Gray is the Australian based podcast host and producer for the show. The production value of the podcast is high and well structured. He always has good interesting interviews and covers the news in an entertaining light-hearted way. If you’re only looking for only one security podcast to listen to, this has to be it.

Crypto-Gram Security - This is Bruce Schneier’s monthly podcast that basically has Dan Henage reading the articles Schneier posted on his website. Depending on how ofter Schneier writes, this podcast can be anywhere from 15 - 45 minutes long. Dan does a great job reading and producing the podcast. It’s a nice way to listen to Schneier articles. I usually pick up new things in the podcast that I missed reading his articles.

Defensive Security - This is another well produced show that takes a blue team approach to discussing topic and news items. From a technical aspect everything is sound. From a presentation standpoint it could use more energy. It is a good podcast that takes a slightly different angle on information security.  

Data Driven Security - This is the latest show I’ve picked up and I’ve loved the two episodes I’ve listened to so far. The topic, as the title suggests, is about data within information security, which might not appeal to everyone. Still it covers metrics within security, which is very much needed in every organization. I’m looking forward to seeing what I can learn from this show.

This post first appeared on Exploring Information Security.

Infographic Friday October 10, 2014

Presented by Duo Security

This post first appeared on Exploring Information Security.