Supply chain attacks and the infosec skills shortage
This is the ppfosec bi-weekly newsletter where I cram all my readings of infosec/technology news and dad jokes in a 15-minute summary. If you like my writing please subscribe and follow me on social media.
This week's spotlight: Supply Chain Attacks
Ever head of Log4Shell?
No, not that.
Long story short, Log4Shell is a software vulnerability in a popular open-source Java library, Log4j, that tricks an application's ability to log activities by injecting a command instead of an event. Log4j executes the malicious command, which basically says: "look up this URL and bring me back its Java code"; then bingo! The attacker controls your application's behaviour. Log4Shell was discovered in December 2021 and the community pretty much lost its mind over it.
The actual attack is more detailed, but this article is not a technical breakdown of Log4Shell. Rather, what interests me are the consequences of this "perfect storm" vulnerability on our perception of supply-chain security. Log4j, after all, is one of the hundreds of open-source software libraries used by all our favourite apps (and even by our not-so favourites). Hint: people are still sort-of bananas about it.
Pictured: Contemporary art evocating being bananas about patching a server for Log4j
Supply chain attacks headlines
Headlines recently surfaced other supply-chain risks, ranging from commercial software vendors to open source modules such as Log4j. For example, we have seen hackers penetrating corporate networks using vulnerabilities in Atlassian products (Jira and Confluence - yes, they still make on-premises versions of these!); or Python modules being infected with malicious code that harvests AWS credentials. These two were just the ones I found in the last week!
Yet, the 2022 AppSec Progress Report by ShiftLeft published last month suggests only 3% of open source bugs are attackable (and only 4% of vulnerable Log4J dependencies were attackable). Therefore, you can ignore vulnerable components to focus on the real danger, which is a tiny fraction! Yay?
While the idea that most vulnerable dependencies are not loaded by the application or used at all might seem like a silver bullet to reduce alert fatigue for developers, I see it as a double-edged sword: software changes fast. A dependency not used or a service that does not take user input today might be tomorrow's exposed component. Suddenly a vulnerability that was snoozed for months resurfaces and you have to go into upgrade hell. No time saved.
Solutions
HackerOne's Senior Security Technologist (not sure what that title means, but "Sr SecTechist" sounds like a Transformer so I love it) had an interesting piece on the subject last week: It's a Race to Secure the Software Supply Chain — Have You Already Stumbled? Most of the recommendations are basically to apply the tried-and-true principles of infosec (classify your assets based on business needs and build an inventory, shift security left, exercise due care with any third party, etc.) Beyond the textbook was this proposition: Evaluate every software vendor based on incident readiness. Most buyers and developers will not think about this. Assume whatever library, software solution or dependency becomes compromised tomorrow morning, and based on your due care, you know how much they will suck at communicating with you and fixing things on time: what is your team's plan?
Finally, the supply chain discussion brings me closer than I ever thought to becoming a DevSecOps advocate. I always felt the model was a bit of a buzzword, though I have to admit adding a security-minded individual to a DevOps team (or, more realistically, split up between 4 or 10 teams - more on skill shortage below) to provide adequate tooling and resources intrigues me. Security works best when the secure option is also the most convenient one. When your "Sec" advisor provides basic "golden" libraries, container images, or hosts images and chimes in if the scanner starts going bumblebee-doo, I think you have a leg-up. Not to be confused with a lego.
Quick Takes
Rapid-fire links with my thoughts.
Random
Paul Sawers
My take: speaking of open source risks! Copilot is almost certainly our pathway to future coding methods. Intellectual property concerns remain. I feel Microsoft/GitHub are lacking transparency.
David Price
My take: AI was starting to slowly become good enough to beat them anyway. Good riddance. I am a security professional and even I hate CAPTCHAs.
Simon Sharwood
My take: Powershell (no relation to Log4Shell) used to be a Windows-centric scripting language used to manage users, mailboxes, servers, workstations, etc. Since it was installed on every Windows device, hackers leveraged it to deliver malicious payloads. However, as this article points out, this is not your papa's Powershell anymore! Powershell runs on Mac and Linux, and with its new embeddings in the Microsoft GraphQL, I feel it has become an exquisitely versatile and fun language to play with. The addition of a run-time virus scanner reduces abuse potential and I am glad agencies are restoring its reputation. I predict a bright future for Powershell. Yes, I love me some Powershell.
Legal Jam
My take: I am a self-professed HIPAA geek, and this piece is worth reading in order to think how we could broaden the definition of health data to other sectors than insurers, healthcare services, and clearinghouses. Right now, in the U.-S., your health metrics collected by your Apple watch are not HIPAA-protected, for example. Should they? I love these questions, LOVE them.
Cost of a breach
I monitor breach settlements to help you build quantitative risk assessments based on real-life data. Most of the costs you see there are only for legal penalties and do not include lawyer fees, crisis management consultants, and reputation loss ( I estimate it as a percentage of the company's marketing budget for the next 3 years).
- CafePress Fined $500,000 After Massive Data Breach (InfoSecurity Magazine). 23 million records. Cost of the fine: $0.022/record
- Carnival Cruise Line pays $1.25M settlement in 46-state breach lawsuit (IAPP) 180,000 records. Cost of the settlement: $6.94/record
- Insurance company Lemonade settles biometric class-action lawsuit for $4M (IAPP) Number of customers not indicated. The now-famous Illinois Biometric Privacy Act ("BIPA"), which handed Facebook a hefty $650,000,000 settlement back in 2020, strikes again. I don't know much about justice procedures, but I am willing to bet many companies dealing in biometrics are more afraid of Illinois than of the European Courts who are being quite slow with GDPR fines.
Threat Intel
Cybercriminals apparently don't bother anymore managing encryption keys: they just threaten to leak confidential information (The Register). Meanwhile, despite our recent focus on supply chain risks, good ol' phishing is still the preferred attack method, as per InfoSecurity Magazine.
My take: One element we cannot disagree with is that companies that cannot afford basic IT and security resources are still getting hit hard.
Michael Kan
My take: I wonder how kids will use deep fakes to trick identity cards in order to get into clubs before they reach drinking age. Yes, I am a dad. My brain just defaulted to this.
Speaking of "getting hired for a tech job"...
This week's rant: Cybersecurity Skill Shortage
Last week I read two articles about the difficulties of people getting into InfoSec, and I wanted to chime in with my thoughts on the matter. Daniel Miessler, who's pretty much a superstar of the infosec world, sees a struggle between the haves (the 5% of big high tech companies) who can afford the best talent, and the have-nots who are scrambling. His conclusion is that the 5% should help, because like it or not we are all in this together.
On the other hand, Ricardo Villadiego, CEO of Lumu Technologies, argues that the skills shortage is a "myth" and that our collective duty should be to obtain better tooling that does not require coding skills in order to augment an organization's security posture.
These articles have a backdrop on social media, where I often see claims such as:
- There are still too many "entry-level" jobs that require a degree, 3-5 years of experience, or both;
- Universities are creating more and more cybersecurity degrees, which have the perverse effect of barring people who cannot afford degrees from entering the field;
- Corporations do not take enough chances on "juniors";
- People who want to get into InfoSec don't see a pathway.
So, what do we have here? An industry that desperately needs talented individuals; talented individuals who just want to be given a chance. Why is there a problem?
I slide with Villadiego. Yes, his article is a not-so-subtle advertisement for his company. That doesn't mean he's wrong. Lets address the elephant in the room: coding, or, more broadly, hard technical skills. I think a lot of people are neglecting the steep learning curve for coding and system administration. IT is not rooted in social, concrete experiences: the concepts are completely abstract. Such challenges are the reason why I think many organizations do not "hire on attitude and potential" alone. And I sort of agree: would you want hospitals to hire nurses without the hard skills? Corporations, even the 5%, would probably argue as well that they already are taking many risks on individuals without prior experience.
I think we should have firewall administrators who don't know bash scripting and who do not master the OSI model. I think our security software should have AI that predicts rulesets and drag and drop components for humans to apply them upon further review. I think we should not learn proprietary querying languages to search logs: we should have NLP programs that translate a vocal command such as "I need to see email traffic for the past 3 weeks" into a query, totally under the hood.
The way I see it, we either try to pressure the 5%, governments, and some FinServ to train people from scratch, or we lower the hard skill entry bar so you can have people who, despite not knowing any Python, build and run security infrastructure. I prefer the latter, and I think AI-powered solutions will get us there (I told you I am a tech optimist).
As always, I am open to discussion!