insert(post, "{ 'standard_disclaimer' : 'My opinion, not my employer\'s' }")
This is a post about the fictional company FredCo. If the context or details presented by the post seem familiar, it’s purely coincidental. This is, again, a fictional story.
Let’s say FredCo had a pretty big breach that (fictionally) garnered media, Twitterverse, tech-world and Government-level attention and that we have some spurious details that let us sit back in our armchairs to opine about. What might have helped create the debacle at FredCo?
Despite (fictional) endless mainstream media coverage and a good chunk of ‘on background’ infosec-media clandestine blatherings we know very little about the breach itself (though it’s been fictionally, officially blamed on failure to patch Apache Struts). We know even less (fictionally officially) about the internal reach of the breach (apart from the limited consumer impact official disclosures). We know even less than that (fictionally officially) about how FredCo operates internally (process-wise).
But, I’ve (fictionally) seen:
- a detailed breakdown of the number of domains, subdomains, and hosts FredCo “manages”.
- the open port/service configurations of the public components of those domains
- public information from individuals who are more willing to (fictionally) violate the CFAA than I am to get more than just port configuration information
- a 2012/3 SAS 1 Type II report about FredCo controls
- testimonies from FredCo execs regarding efficacy of $SECURITY_TECHOLOGY and 3 videos purporting to be indicative of expert opine on how to use BIIGG DATERZ to achieve cybersecurity success
- the board & management structure + senior management bonus structures, complete with incentive-based objectives they were graded on
so, I’m going to blather a bit about how this fictional event should finally tear down the Potemkin village that is the combination of the Regulatory+Audit Industrial Complex and the Cybersecurity Industrial Complex.
“Tear down” with respect to the goal being to help individuals understand that a significant portion of organizations you entrust with your data are not incentivized or equipped to protect your data and that these same conditions exist in more critical areas — such as transportation, health care, and critical infrastructure — and you should expect a failure on the scale of FredCo — only with real, harmful impact — if nothing ends up changing soon.
From the top
There is boilerplate mention of “security” in the objectives of the senior executives between 2015 & 2016 14A filings:
- CEO: “Employing advanced analytics and technology to help drive client growth, security, efficiency and profitability.”
- CFO: “Continuing to advance and execute global enterprise risk management processes, including directing increased investment in data security, disaster recovery and regulatory compliance capabilities.”
- CLO: “Continuing to refine and build out the Company’s global security organization.”
- President, Workforce Solutions: None
- CHRO: None
- President – US Information Services: None
You’ll be happy to know that they all received either “Distinguished” or “Exceeds” on their appraisals and received a multiplier of their bonus & compensation targets as a result.
Furthermore, there is no one in the make-up of FredCo’s board of directors who has shown an interest or specialization in cybersecurity.
From the camera-positioned 50-yard line on instant replay, the board and shareholders of FredCo did not think protection of your identity and extremely personal information was important enough to include on three top executive directives and performance measure and was given little more than boilerplate mention for others. Investigators who look into FredCo’s breach should dig deep into the last decade of the detailed measures for these objectives. I have first-hand experience how these types of HR processes are managed in large orgs, which is why I’m encouraging this area for investigation.
“Security” is a terrible term, but it only works when it is an emergent property of the business processes of an organization. That means it must be contextual for every worker. Some colleagues suggest individual workers should not have to care about cybersecurity when making decisions or doing work, but even minimum-wage retail and grocery store clerks are educated about shoplifting risks and are given tools, tips and techniques to prevent loss. When your HR organizations is not incentivized to help create and maintain a cybersecurity-aware culture from the top you’re going to have problems, and when there are no cyberscurity-oriented targets for the CIO or even business process owners, don’t expect your holey screen door to keep out predators.
Awwwdit, Part I
NOTE: I’m not calling out any particular audit organization as I’ve only seen one fictional official report.
The Regulatory+Audit Industrial Complex is a lucrative business cabal. Governments and large business meta-agencies create structures where processes can be measured, verified and given a big green ✅. This validation exercise is generally done in one or more ways:
- simple questionnaire, very high level questions, no veracity validation
- more detailed questionnaire, mid-level questions, usually some in-person lightweight checking
- detailed questionnaire, but with topics that can be sliced-and-diced by the legal+technical professions to mean literally anything, measured in-person by (usually) extremely junior reviewers with little-to-no domain expertise who follow review playbooks, get overwhelmed with log entries and scope-refinement+reduction and who end up being steered towards “important” but non-material findings
Sure, there are good audits and good auditors, but I will posit they are the rare diamonds in a bucket of zirconia.
We need to cover some technical ground before covering this further, though.
Shocking Struts
We’ll take the stated breach cause at face-value: failure to patch an remote-accessible vulnerability with Apache Struts. This was presented as the singular issue enabling attackers to walk (with crutches) away with scads of identify-theft-enabling personal data, administrator passwords, database passwords, and the recipe for the winning entry in the macaroni salad competition at last year’s HR annual picnic. Who knew one Java library had so much power!
We don’t know the architecture of all the web apps at FredCo. However, your security posture should not be a Jenga game tower, easily destroyed by removing one peg. These are all (generally) components of externally-facing applications at the scale of FredCo:
- routers
- switches
- firewalls
- load balancers
- operating systems
- application servers
- middleware servers
- database servers
- customized code
These are mimicked (to varying levels of efficacy) across:
- development
- test
- staging
- production
environments.
They may coexist (in various layers of the network) with:
- HR systems
- Finance systems
- Intranet servers
- Active Directory
- General user workstations
- Executive workstations
- Developer workstations
- Mobile devices
- Remote access infrastructure (i.e. VPNs)
A properly incentivized organization ensures there are logical and physical separation between/isolation of “stuff that matters” and that varying levels of authentication & authorization are applied to ensure access is restricted.
Keeping all that “secure” requires:
- managing thousands of devices (servers, network components, laptops, desktops, mobile devices)
- managing thousands of identities
- managing thousands of configurations across systems, networks and devices
- managing hundreds to thousands of connections between internal and external networks
- managing thousands of rules
- managing thousands of vulnerabilities (as they become known)
- managing a secure development life cycle across hundreds or thousands of applications
Remember, though, that FredCo ostensibly managed all of that well and the data loss was solely due to one Java library.
If your executives (all of them) and workers (all of them) are not incentivized with that list in mind, you will have problems, but let’s talk about the security challenges back in the context of the audit role.
Awwwdit, Part II
The post is already long, so we’ll make this quick.
If I dropped you off — yes, you, because you’re likely as capable as the auditors mentioned in the previous section on audit — into that environment once a year, do you think you’d be able to ferret out issues based on convoluted network diagrams, poorly documented firewall rules and source code, non-standard checklists of user access management processes?
Let’s say I dropped you in months before the known Struts vulnerability and re-answer the question.
The burden placed on internal and — especially — external auditors is great and they are pretty much set up for failure from engagement number one.
Couple IT complexity with the fact that many orgs like FredCo aren’t required to do more than ensure financial reporting processes are ?.
But, even if there were more technical, security-oriented audits performed, you’d likely have ten different report findings by as many firms or auditors, especially if they were point-in-time audits. Furthermore, FredCo has has decades of point-in-time audits but hundreds of auditors and dozens of firms. The conditions of the breach were likely not net-new, so how did decades of systemic IT failures go unnoticed by this cabal?
IT audit functions are a multi-billion dollar business. FredCo is partially the result of the built-in cracks in the way verification is performed in orgs. In other words, I posit the Regulatory+Audit Industrial Complex bears some of the responsibility for FredCo’s breach.
Divisive Devices
From the (now removed) testimonials & videos, it was clear there may have been a “blinky light” problem in the mindset of those responsible for cybersecurity at FredCo. Relying solely on the capabilities of one or more devices (they are usually appliances with blinky lights) and thinking that storing petabytes of log data are going to stop “bad guys’ is a great recipe for a breach parfait.
But, the Cybersecurity Industrial Complex continues to dole out LED-laden boxes with the fervor of a U.S. doctor handing out opioids. Sure, they are just giving orgs what they want, but it doesn’t make it responsible behaviour. Just like the opioid problem, the “device” issue is likely causing cyber-sickness in more organizations that you’d like to admit. You may even know someone who works at an org with a box-addition.
I posit the Cybersecurity Industrial Complex bears some of the responsibility for FredCo’s breach, especially when you consider the hundreds of marketing e-mails I’ve seen post-FredCo breach telling me how CyberBox XJ9-11 would have stopped FredCo’s attackers cold.
A Matter of Trust
If removing a Struts peg from FredCo’s IT Jenga board caused the fictional tower to crash:
- What do you think the B2B infrastructure looks like?
- How do you think endpoints are managed?
- What isolation, segmentation and access controls really exist?
- How effective do you think their security awareness program is?
- How many apps are architected & managed as poorly as the breached one?
- How many shadow IT deployments exist in the ☁️ with your data in it?
- How can you trust FredCo with anything of importance?
Fictional FIN
In this fictional world I’ve created one ending is:
- all B2B connections to FredCo have been severed
- lawyers at a thousand firms are working on language for filings to cancel all B2B contracts with FredCo
- FredCo was de-listed from exchanges
- FredCo executives are defending against a slew of criminal and civil charges
- The U.S. Congress and U.K. Parliament have come together to undertake a joint review of regulatory and audit practices spanning both countries (since it impacted both countries and the Reg+Audit cabal spans both countries they decided to save time and money) resulting in sweeping changes
- The SEC has mandated detailed cybersecurity objectives be placed on all senior management executives at all public companies and have forced results of those objectives assessments to be part of a new filing requirement.
- The SEC has also mandated that at least one voting board member of public companies must have demonstrated experience with cybersecurity
- The FTC creates and enforces standards on cybersecurity product advertising practices
- You have understood that nobody has your back when it comes to managing your sensitive, personal data and that you must become an active participant in helping to ensure your elected representatives hold all organizations accountable when it comes to taking their responsibilities seriously.
but, another is:
- FredCo’s stock bounces back
- FredCo loses no business partners
- FredCo’s current & former execs faced no civil or criminal charges
- Congress makes a bit of opportunistic, temporary bluster for the sake of 2018 elections but doesn’t do anything more than berate FredCo publicly
- You’re so tired of all these breaches and data loss that you go back to playing “Clash of Clans” on your mobile phone and do nothing.
This is not cool.
First it was OpenDNS selling their souls (and, [y]our data) to Cisco (whom I don’t trust at all with my data).
Now, it’s Dyn — — doing something even worse (purely my own opinion).
I’m currently evaluating offerings by [FoolDNS](http://www.fooldns.com/fooldns-community/english-version/) & [GreenTeam](http://members.greentm.co.uk/) as alternatives and I’ll post updates as I review & test them.
I’m also in search of an open source, RPi-able DNS server with regularly updated Squid-like categorical lists and the ability to white list domains (suggestions welcome in the comments).
I’m a cybersecurity data scientist who knows just what can be done with this type of data when handed to `$BIGCORP`, and I’m far more concerned with Oracle than Cisco, but I’d rather work with a smaller company who has more reason to not sell me out.