I certainly believe while we have moved past the tip of the iceberg, we're nowhere done with #log4j and it's issues. EVERYONE is now looking at this package and finding new variants and even new vulns. Don't expect to sleep anytime soon my dear #infosec fam.
1/
That said, remember there are likely malicious actors out there looking for the next thing already. With log4j burnt and orgs rapidly applying mitigations and fixes, what next? Where do we find the next widely used package with significant vulnerabilities like this?
2/
With that in mind, please drop the adversarial bullshit. I've seen devs abdicating all responsibility for the maintainers. I've seen security folks hating on devs. The mistakes made that led to this vuln. are laughably easy (to us as #infosec professionals).
3/
However, how many of you pointing fingers are out there contributing? Are you helping maintainers understand their threat models and playing an active role in OSS yourself? No? Well perhaps there's an opportunity for you there? Oh it's not your job??
4/
The vast majority of OSS maintainers don't get paid for their efforts. The cooperative community effort is what is supposed to make OSS great.
But devs, don't you go feeling all vindicated either. The fact is these mistakes were basic AF. There's no excuse for that either.
5/
It's not like we haven't been aware of simple things like input validation for the better of two decades now. It's an active and lazy choice not to do it. And you don't get to hide behind this imaginary shield of OSS liability transfer either.
6/
And to the orgs that leverage OSS without contributing time and effort to assess libraries for vulnerabilities, you're at fault too. You profit off the community but then don't help secure the exact packages you leverage from it?? You've exacerbated this issue.
7/
So, TL/DR; We're a long way from the end of this mess. There will inevitably be more. So stop pointing fingers at each other and let's figure out how we work together to fix our crap.
/FIN
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Hey #infosec peeps, many of us are tired, frustrated, and exasperated by #Log4Shell.
That said, how about we not blast developers en-masse or even within OSS or even within the Log4j project. Let's remember we have culpability here as well.
1/
We did nothing with a warning that was given to us in 2016 at BlackHat. Not one detection rule or scanner policy was created.
Despite extensive OSS security research done by orgs and academia, we failed to find this vuln in probably the single most popular Java package.
2/
How many of us are scrambling now because basic security controls (WAF's, Outbound connectivity lockdowns, etc.) that could have limited/prevented exploit of this vulnerability don't exist in our environments?
3/
Thursday morning, back home after a few days of board meetings and I have some thoughts to share on being effective in board presentations. Tech and security leaders still seem to struggle in these settings so here goes:
As always, it's a 🧵
1/
1. Research your board members. Find out in advance who you'll be presenting to and look up their background. Talk to your peers who've chatted with the board before, see what intel you can get from them on the dynamics of those discussions. Prep accordingly.
2/
2. Read the room. Important with any presentation but particularly so in the board room. If they're looking at their phones, you lost them. It maybe that you got to technical. Change things up, change your tone, elevate the message and grab their attention again.
3/
The number of potentially qualified people that I see self-eliminating from open #infosecjobs saddens me. The thing is when you're looking at job descriptions, there are two ways you can look at them.
In typical Alyssa fashion, a 🧵 follows:
1/
Some people will read through the requirements from an implicit mindset of identifying the reasons not to apply. They look for any requirements that suggest they're not qualified and when they find too many of them (for some that means even one), they choose not to apply.
2/
The other method, and the mindset I wish more job seekers would take, is to look at a job description with the focus of finding the reasons to apply. What requirements are things you're good at or could be good at. What responsibilities are areas of interest for you.
3/
Forty-seven trans people have been violently killed so far in 2021. While this number represents an increasing trend, let's talk about what that number doesn't tell us.
* These are violent crimes, meaning someone else took their lives. This number does not reflect those that took their own lives as a result of unmanageable pressures of discrimination, abandonment, homelessness, forced conversion therapy, etc.
2/
* This number only includes those situations where Law Enforcement documents the victim as transgender. It does not include those killed where police and families hid the gender identity of the victim. This is a common occurrence and skews the numbers heavily.
3/
One of the worst habits we have in security is speaking in absolutes. Saying things like "Unhackable", "Breachproof", "Fully Secure", "No Risk". They're simply untrue.
But this also includes when we talk about skillsets. There are no absolutes.
1/
So when someone says, "You must know x, y, z" or "You have to do a, b, c" to get a certain job (or any job) in security, you can simply toss out those absolutes in with all the other fallacious absolutisms that security people throw around. Simply ignore them.
2/
The reality is we need people of all different skillsets, all different backgrounds, and with all different perspectives in order to be successful. Security is about problem solving and problem solving is strongest when different viewpoints collaborate.
3/