During this election cycle CyberSecurity took center stage. While so much attention was focused on the “400-lb hacker” and external threats from Russia and China–the reality is that according to recent reporting, 90% of organizations experience at least one case of insider threat each month. That’s a sobering statistic that no one wants to see escaping the four walls of the next SecOps meeting. As security professionals we are all concerned about the growing cases of insider threats within our organizations, whether well-intended mistakes or mal-intended attacks for personal gain.
It is paramount that we address four key challenges that make our jobs difficult in assessing and finding insider threats:
- Auditability: Who really last touched the keyboard? How can we know for sure?
- Reportability: How will the actual Risk Acceptor be notified of an issue? How accurate and factual is the reporting from the GRC Solution to what’s actually going on an Enterprise’s cloud infrastructure? How quickly do changes made to the approved baseline get reported and/or remediated? In short, once approved, how would the Risk Management Team know that it changed and was subsequently fixed?
- Visibility: You cannot protect that which you cannot see (or at least, think you can see.) The right mix of security tools/solutions should give the Enterprise full visibility into what is going on across your entire cloud infrastructure stack.
- Transparency: Can key members of the Governance-Risk-Compliance (GRC) / Security staff actually ‘see’ how the Enterprise GRC and Security policies are actually being implemented? Will they be notified in a timely fashion if an issue persists? How will residual risk be categorized and reported?
With those challenges in mind, I thought it would be interesting to explore the Good, the Bad and the Ugly of Insider Threats related to Public Cloud environments to see where we stand today.
Thankfully, many lessons learned from existing IT architectures can be directly applied to Public Cloud.
Most of us have well-defined Insider Threat Processes
Maybe our process is not exactly perfect, but at least we ‘know’ we should have them and/or are in the process of improving our existing ones. We (mostly) understand our existing IT architectures. Maybe not completely, but at least we have done the homework and identified our ‘crown jewels’. We’re more aware about [LEAST_PRIV] (Emphasis added for the old timers like me, who preferred [ALL CAPS] to highlight a Security Control in regular written communications!) Some of us lived through Snowden and other well-publicized (and not so well-publicized) incidents by insider threats and appreciate the complexity of being able to produce the right type of forensic data for internal / external investigators in a timely manner…
(Perceived) Reality: Most of us are still struggling with the above but we fully accept that we need to get up-to-speed since moving to Cloud is here to stay and we’re not sure if our current set of tools and processes will work as expected.
We have put into place a security stack that provides (some?) visibility
Most of us have a well-defined security stack. We’ve spent a large amount of resources (time / money / people) to create our current stack. We think it will work for Cloud. But we also realize that it may not initially have complete parity with respect to integration and visibility. We have extensive tools to protect our: Applications / Data / Endpoints / Networks / and Servers. We know our current stack is mostly resilient, but what we don’t know is how well it will perform in a Cloud environment.
(Perceived) Reality: We wish the security stack was better integrated and better understood by all members of the Leadership Team, especially the General Counsel and/or Internal Auditors / GRC Team Members. We periodically receive well-crafted and sometimes actionable information that provides us with ‘ground truth’ on what is really going on at the IT Instance (e.g. Server, Application, Database, etc.) / Infrastructure level.
Active Monitoring vs. Passive
Near-real time or Real-time are favored marketing phrases, but what we’re really talking about is the difference between minutes vs. days/weeks/months. The reality is that depending on the scan intervals and associated reporting of an alert plus the time that it takes to actually respond to it, the actual time it takes will be a fuzzy ‘it depends’. Expert knowledge of the underlying Cloud Infrastructure API is paramount for success into providing the aforementioned challenges.
Not all GRC/Security Solutions are Equal
No surprise here, but the harsh Cloud Security reality is that unless you’re actively monitoring changes to both the Data AND Management Control Planes, you may remain blind to what’s really going on.
Big Data Problem
Big Data seems to be a problem everywhere. It remains true today as it was a few months/years past: the amount of data that Security Analysts must process is huge. Add to it the complexity and reality of elasticity to a given set of Enterprise Cloud Resources, if you thought your Cybersecurity Data problem was big before, it’s now going to grow exponentially. Heavily regulated IT infrastructures (e.g. Finance/Health/Government Sectors, etc.) not only need to decide how to store audit logs, etc. but must also now deal with the need to quickly parse that information should the need arise to quickly deep-dive into it for forensic purposes.
Tool / Information Integration
Many have personal war stories and even scars to show how difficult it sometimes is to stitch together a congruent set of tools and make them appear to work, or at the very least, report as ‘one’. Unfortunately, many vendors do not practice Open Standards nor leverage common APIs. Those who do, can easily rise to the top of the short list of available Cloud Security tools.
The End Point Problem
Irrespective of how robust your Cloud Security stack is, there remains a common threat vector that unless it’s addressed, may serve as the real Achilles’ heel of Public Cloud. The endpoint (Not to be confused with AWS Endpoints, that’s different). For purposes of this portion of the discussion, I mean to say any device (Mobile or otherwise) that has access to a Management Console that can be compromised. Yes, that particular portion of the Cybersecurity market is full of ‘Next Generation <insert existing Cybersecurity mouse trap>’ Unfortunately, there are only a handful of real solutions that are actually addressing the problem vs. building a shinier mouse trap. Enough said.
The real issue remains true in Public Cloud as it does in existing On Premises Datacenters: Elevated Privilege is (still!) KING. Unless an Enterprise protects the very Endpoints it’s DevOps team uses to manage its Cloud Infrastructure, this remains a ripe threat vector for bad actors (Internal and External).
Internal Threats via Rouge Admins, Trusted Insiders, Disgruntled Employees, etc.:
I’ve long argued dealing with the insider threat is not a technology problem but a personnel problem to solve. Yes, technology can and does help identify potential behavior that may develop, if not addressed, into activity that may destroy an Enterprise’s sensitive data, reputation, decreased shareholder valuations, and more.
Unfortunately, we still don’t know what we don’t know. But we’re hoping our Enterprise SIEM of choice will magically poop out the right golden nugget and/or needle in the ginormous audit log haystack.
HINT: Garbage In / Garbage Out still applies in today’s cloud environments. IMHO, Data Science solutions can and should be leveraged to address this need. SIEMs should not be expected to unilaterally solve this problem.
Even the Clint Eastwood film had a somewhat happy ending for everyone (except perhaps for the mercenary insider threat, Angel Eyes), so I’ve got to finish with a few golden nuggets.
Adopting a cloud security infrastructure solution with compliance automation and attribution features can absolutely help you in determining if your AWS Infrastructure is compliant and identify potential key threat vectors that could be exploited by bad actors (Insider / Outsider Threats) by scanning your entire footprint across all AWS Services and Regions and providing actionable events. Additionally, by leveraging correlated information, these modern platforms can provide you with ‘Who last touched the keyboard?’ level of information known as ‘User Attribution.’
[su_box title=”About Sebastian Taphanel” style=”noise” box_color=”#336588″][short_info id=’99036′ desc=”true” all=”false”][/su_box]