Information Security Archives - Andres Andreu, CISSP-ISSAP, QTE

Attack Surface Management in the Cloud Era

Attack Surface Management in the Cloud Era: The Many Angles to Consider. This was the title of my talk on a invitation-only conference (2/21/2023) with “Executive Insights”. In this blog I share the material while trying to recount what I actually said during the live session. The session was 15 minutes long with 5 minutes of Q&A. Hence, the content is not intended to be granular or exhaustive.

Note: This is an ultra important topic for cybersecurity leaders who are truly focused on understanding their ecosystem and where to focus protective resources (human and dollars).

Slide 1

Attack surface management is a complex endeavor. Unfortunately a number of products in this space have marketed very well. In turn, some people in cybersecurity think that the purchase and deployment of some specific product actually gives them a handle on their attack surface. What I would like to share with you now are some angles to consider so that you may possibly expand your program to cover your organization in a more thorough way.

Slide 2

External perspective

The overt, and best known, space in regards to attack surface management is that of the external perspective. By that I mean what your organization looks like to the outside world, in particular to nefarious actors. This outside-in perspective generally focuses on public internet facing resources, especially for businesses that actually sell, or host, web based products. The angles here mostly focus on which hosts are public facing and in turn what ports are actively listening per host. A good solution here actually probes the listening ports to verify the service being hosted. For the sake of accuracy and thoroughness please don’t assume that everyone adheres to IANA’s well known port list. It is entirely possible, for instance, to host an SSH server on TCP port 80 and that would inaccurately imply that a web server is at play.

Shadow IT

A benefit of focusing on this outside-in angle is that it is a great way to expose shadow IT elements, if they exist and are hosting in a public facing capacity. I should also state that for this set of angles to be effective this has to be a continuous process such that new public facing hosts and ports are discovered in a rapid fashion. There are many products that serve this space and provide relevant solutions.

B2C / B2B

From the external perspective the natural focus is on the Business to Consumer (B2C) angle. This is where the space is predominately based on end-users/customers and web applications. All of what makes up a web app stack comes into play there. But from a Business to Business (B2B) perspective there is the lesser familiar area of APIs. Whether you run a REST shop or a GraphQL shop there are unique challenges when protecting APIs. Some of those challenges revolve around authentication, authorization, and possible payload encryption in transit. For instance is TLS enough by way of protecting data in transit? Or do you consider an orthogonal level of protection via payload encryption, something like JSON Web Encryption (JWE) (if you use JSON Web Tokens (JWT)) for instance. It’s certainly an angle that needs consideration.

Slide 3

Covertly there are a number of angles that require attention. Starting with the humans lets focus on insiders (meaning inside of your network).

Insiders

There are threats and employees. Sometimes an employee becomes a threat and the angle here is that they are already inside your network. This angle is typically one where there is high risk because employees have authenticated access to sensitive systems and data. To complicate this, enter hybrid or work from home setups. Now your attack surface has expanded to areas outside of your control. Home networks are clearly high risk environments but since our traditional network perimeters no longer exist, now those home networks are part of your attack surface. Imagine a home network with kids downloading all kinds of crazy stuff. Then imagine a user that has your hardened work laptop at home. Then imagine the day that person feels like accessing work content from their personal machine. Or better yet they figure out how to copy crypto certificates and VPN software to their personal machines. Now the angle is an insecure machine, with direct access to your corporate network, that in turn has direct access to your cloud environments.

Non-generic computing devices

In reference to non standard computing devices there are risks based on this equipment being generally unknown to traditional IT teams. Imagine the HVAC controllers, or motors, or PLCS, required to operate the building you work in. Most of those devices are networked with IP addresses, they typically reside on your network and are part of your attack surface. Now let’s also consider the administrators of said equipment and the fact that they have remote access capabilities. Some VPN paths bring traffic in via your cloud environments with paths back to the building equipment. That is one angle. Then there are direct remote access scenarios, which put people on to your network and in turn there is the possibility of access to your cloud environment. Misconfigurations like these happen all the time and are angles to be considered when studying your attack surface.

SaaS

Supply chain angles are now a big thing. Actually they have been for some time but recently they are getting a lot of industry attention. Let’s start with SaaS solutions. Are they your responsibility from a security perspective? Maybe, maybe not. But, your data goes into these systems. While it is an organizationally subjective decision if your data in a SaaS solution is part of your attack surface, it is an angle to consider. You should at least scrutinize the security configuration of the SaaS components that get accessed by your employees. The goal is to make sure the tightest security configurations possible are in use. Too often consultants get brought in to set SaaS environments up and they may take the easiest path to a solution, meaning the least secure. It happens.

SaaS integrations are even riskier. Now your data is being exchanged by N number of SaaS solutions outside of your control and again, it’s your data being sent around. Were those integrations, typically API based, configured to protect your data or purely to be functional? After all my years in the industry, I can tell you what I have seen puts me in the cynical category based on people doing what is most secure on your behalf.

FOSS

Part of modern day supply chains is open source code. We all know of the higher profile cases that involved negative events based on abuse of things like open source libraries. The angles here vary but I assure you most cloud environments are full of open source code. It is an angle that cannot be avoided in the modern world.

Slide 4

Alternate ingress pathways

A typical cloud setup only accepts sensitive network connectivity from specific networks. This is by design so that sensitive communication paths, like SSH, are not accessible via the public internet. Typically these specific networks are our corporate networks and those, in turn, get remotely accessed via VPNs. Or it could also be the case that your VPN traffic itself flows into, and/or through, your cloud environment. So an angle to scrutinize is exactly where do VPN connections get placed on your network. This may be leaving pathways open to your cloud infrastructure.

Another pathway of concern is direct, browser based, access to your cloud infrastructure. A successful authentication could give a user a privileged console for them get work done. If this account gets compromised then there is substantial risk. The real danger with this ability is that it facilitates users to log in and do their work from personal machines that may not have the same protective controls as a work computer.

Privileged Users

SRE engineers and sysadmins typically have elevated privileges and the ability to make impactful changes in cloud environments. The scripts and tools they use need to be considered as part of your attack surface because I am sure your teams didn’t write every piece of software they use. And so these scripts, the SRE engineers machine, etc all become possible alternate access paths to sensitive elements.

DataBase Administrators (DBA) are valued team members. They typically have the most dangerous levels of access from a data perspective. This is obvious given their role but this also should raise your risk alarms. Imagine a DBA working from a home based machine that for instance has a key logger on it. This is a machine that will also have data dumps at any given time. And of course we all know that DBAs and software engineers always sanitize data dumps for local working copies *[Sarcasm]*.

Git

Git – there are so many known examples of sloppy engineering practices around hard coded, and in turn, leaked elements of sensitive data. One important angle to study is the use of secrets managers. Analysis must take place to sniff out hard coded credentials, API keys, passwords, encryption keys, etc and then ensure re-engineering takes place to remove those angles from your attack surface. The removal obviously being a migration to use a secrets manager as opposed to statically storing sensitive elements where they are just easy to access.

SSH

SSH tunnels and back-doors are both interesting and challenging. Unquestionably they represent a set of angles you need to hone in on. Detecting if some SSH traffic is a reverse tunnel is not trivial. But from an attack surface perspective you can hardly point a finger at something that introduces this much risk. This scenario can expand your attack surface in a dangerous and stealthy way.

Ephemeral port openings

Temporary openings are a real problem. Ephemeral entities within cloud deployments are challenging enough but the legitimate ones are typically not public facing. So for example let’s say you have containerized your web servers. And you are using elastic technology and possibly orchestration to successfully react to traffic spike. That is an ephemeral use case that is acceptable, and typically behind protective layers (Web App Firewall, etc). But what happens when the human factor creates bypasses to controls in order to facilitate ease of use in a specific scenario.

Story – In talking with some members of a start-up playing in this space they were telling me about one of their interesting findings on a project. They discovered a case where a specific host, on a specific port, was open on specific days for a limited amount of time. Their investigation led to the finding of the SRE and DBA teams having an automated process to allow for the running of a remote maintenance script hitting a database server directly. The SRE / DBA teams felt it was such a limited exposure that there was no risk. Interesting angle from an attack surface perspective and maybe one more people need to look for.

Slide 5

Data

Data. The real target and the heart of our challenges. This is also where multiple angles exist. Let’s start with some simple questions, each one should make you realize the angles at play …. In regards to all of the data you are responsible for, do you definitively know where it all is? Do you know all of the databases at play? Do you know every storage location where files are stored? Within those answers, do you truly know where all of your Personally Identifiable Information (PII) and/or Protected Health Information (PHI) data is? If you don’t then those are angles you need cover ASAP.

Once you know where the data is … then for each location you need to at least map ingress pathways. What can touch database X? Web apps, admin scripts, APIs, people? And what about egress pathways? Once someone touches a data store how can they exfiltrate? The angles within the ingress / egress challenge can be vast and some skilled analysis needs to take place in order to properly understand this part of your attack surface.

In Transit

Another data related angle to consider is that of your data in transit. But not to the outside world, on the inside of your cloud environment. More often than not the following scenario is real …. You have strongly protected TLS 1.2+ streams from the outside to a tier of load balancers controlled by your cloud provider. The load balancers terminate the relevant sockets and in turn terminate the stream encryption at play. From that point to the back-end all of the streams are in the clear. A lot of people assume that is a trusted part of the network. I am not in the business of trust and so that angle bothers me and I push for encrypted streams on the inside of my cloud environments. Otherwise that part of your attack surface is susceptible to prying eyes.

Meta-data

Finally I would like to stress the potential value of proper analysis of meta-data. Take encrypted channels of communication as an example. If an encrypted egress path is identified then some skillful reconstruction of meta-data can yield some valuable intelligence even though you obviously can’t see the content that was moved along the discovered channels.

Thank you for having me, I will take questions now …

Had a great Q&A Session with Education Technology Insights

^{Src: https://unsplash.com/photos/HwWBTd21wiA?utm_source=unsplash&utm_medium=referral&utm_content=creditShareLink}

I recently had a great Q&A Session with Education Technology Insights where I shared some thoughts. The subject was Cybersecurity and some general thoughts on what is currently, and what may be coming. This was enjoyable in that it had me step back a bit and think about the bigger, more abstract, picture.

The questions they asked me:

1. What are some of the major challenges and trends that have been impacting the Cybersecurity space lately?

2. What keeps you up at night when it comes to some of the major predicaments in the Cybersecurity space?

3. Can you tell us about the latest project that you have been working on and what are some of the technological and process elements that you leveraged to make the project successful?

4. Which are some of the technological trends which excite you for the future of the Cybersecurity space?

5. How can the budding and evolving companies reach you for suggestions to streamline their business?

The name of the article with my perspectives is “Protecting Critical Space Assets from Cyber Threats” and it can be found here: link.

Cybersecurity metrics, the challenge, measure what matters

Cybersecurity metrics, the challenge, measure what matters.

Warning: there are a number of somewhat abstract concepts presented here. I know some people have a hard time with abstraction so please read with an open mind. There are a lot of open ended questions as well. This article is intended to spark thought outside of the norm as it relates to cybersecurity metrics.

As an industry we ([cyber | information] security) have struggled to pin down the art, and science, of cybersecurity metrics. It is a struggle that some feel they have mastered. I am not entirely convinced. Moreover, I see the general consensus sadly playing in the safe zone when it comes to this subject. It takes courage to measure what matters as opposed to measuring what is possible, or easy. It also takes courage to measure elements that are somewhat in the abstract because of the difficulty at hand.

I acknowledge that “what matters” is subjective to four entities, the organization, its C-Suite, its varying board members and us (Cybersecurity leadership). We can steer the conversation once there is internal clarity in reference to the items that really matter.

One of the enemies we have to contend with, is our indoctrination to always strive for 100%. This score, level, grade, is simply unachievable in most environments. And what really constitutes 100%? Is it that our organization has been event-less by way of incidents, breaches and/or data exfiltration? What constitutes the opposite, or a score 0 (zero)? We have to stop thinking like this in order to get a realistic sense of metrics that matter.

My contention is that we need a small, tight, set of metrics that are representative of real world elements of importance. This comes with a fear alert, because in some cases measuring these areas will show results that come off as some type of failure. We need not feel like this is reflective of our work, we are merely reporting the facts to those who need them. “Those” would generally be the board and the C-Suite. They will probably have a hard time initially understanding some of these areas and admittedly they are very difficult to measure/quantify.

It is the job of an effective CISO to make sense of these difficult to understand areas and educate those folks. But, the education aspect is not just about understanding them, but to how extract value from them. This is where the courage comes in because a lot of people have a hard time accepting that which is different than what they are accustomed to.

Subjectivity is important here. There are few formulas in the world of cybersecurity and what matters to one organization may have little relevance elsewhere. Organizations need to tailor their goals, and in turn the measuring mechanisms, based on what matters to them. This of course has a direct impact on what risk areas come to light, which ones need to be addressed with urgency and those that can wait. Hitting these subjective goals (that should be defined by the metrics) could also bring about ancillary benefits. For instance this could force the issue of addressing technical debt or force a technology refresh.

Here are some suggestions (nowhere near exhaustive) that are top of mind in respect to metrics we tend not to pursue (mainly due to the difficulty of measuring them):

Effectiveness of active protection mechanisms – This one seems obvious at face value. Grab some statistics after the implementation of some solution, for instance a Web Application Firewall (WAF) and show how many awful things it has prevented. But this is such a fragmented perspective that it may provide a false sense of security. What about your machine to machine communications deeper in your network (VPC or otherwise)? How are you actively protecting those (API requests/responses, etc) entities?

I find the bigger challenge here is ecosystem wide coverage and how you show the relevant effectiveness. There are other difficult to measure areas that directly impact this one, such as attack surface management. But if we, as an industry, are ever going to get ahead of attackers, even in the slightest way, this is an area we all need to consider.

Reproducibility – The “X as a Service” reality is here and quite useful. “X” can be infrastructure, it can be software, it can be many things depending on the maturity and creativity of an organization.

From the software perspective, what percentage of your build process exists within a CI/CD pipeline, or process? This strongly sets a reproducibility perspective. Within a CI/CD process many areas, such as security, resilience and DR, can be covered in automated fashion. Vulnerability management, and patching, can be included here as well. It’s 2022 and if your organization hasn’t invested in this area you need to put some metrics together to make a case for this.

Attack Surface Management – What does your organization look like to an outsider? What does it look like to an insider? What does it look like when you factor in ephemeral entities (such as elastic cloud resources)? Does your attack surface data factor in all assets in your ecosystem? What about interdependencies? Asset inventories are seldom accurate and so possibly your attack surface is a snapshot in time as opposed to something holistic.

There is a lot to consider in terms of attack surface metrics yet it is such a key component to a healthy cybersecurity program. Please don’t think that any one specific product will cover you in this area, most are focused on external perspectives and miss the insider threat vector entirely.

Software Security – This is an enormous subject and one that deserves an entire write itself. The maturity of software can certainly be measured with techniques like SAMM (one such model is OWASP SAMM). Creating, and implementing, a SSDLC goes a long way in integrating security into the core software development process. Underlying any of these techniques is the need to map software to business processes. Otherwise you have a purely technical set of metrics that no one outside of tech will be able to digest.

Technical Debt – This area is complex as it can contextually refer to software that needs to be refactored or it can refer to legacy systems (stagnant or otherwise). Regardless of the context how does one measure the level, or severity, of technical debt within an organization? If a successful relevant model is created it will probably create a strong argument for some budget 🙂

Distance Vector – How far into your ecosystem can an attack get before it is detected and handled (whatever handling means to your organization)? The logic here is simple, the longer it takes to detect something the more you need to pay attention to that area. Think of APTs and how long some of them exist inside of your network before there is detection and response.

Time vector – Who is faster you, the defender, or the attackers? There is a reality to the time factor and every time your organization is targeted there is a bit of a race that takes place. Where you end up in the final results of that race dictate, to an extent, the success factor of an attack. This is very hard to measure. But, spending time figuring out ways to measure this will yield an understanding of the threats you face and how well you will fair up against them.

One great benefit of spending time assessing your time vector is that it will force you to measure your ability to successfully address entire families, or classes, of attacks. Having the macro focus, as opposed to the typical micro focus may bring about an interesting level of discipline with your technical teams. Basically, they will be forced to think big and not exclusively on edge, or corner, cases.

Repeatability – How repeatable are key functions within your organization? Measuring repeatability is super difficult and yet this is a foundational aspect of mature cybersecurity programs. Playbooks exist for this exact reason and we do invest resources into creating, and maintaining, them. This means repeatability is undeniably important but yet how do we quantify this?

Budgeting – How do we know if enough is being funneled into a security program? At the end of the day we can’t plug every hole. One strategy is to perform crown jewel assessments and focus on those resources. Another one is to analyze attack surface data and cover areas of importance. But how do we measure the effectiveness of these, and any other related, strategies?

Insufficient budget obviously reduces the ability of a security team to implement protective mechanisms. The metrics we focus on need to push for clarity in terms of what becomes possible. There’s most likely no correct amount of budget but we get a slice of some larger budget. What we get becomes a variable amount over some period of time. But the budget itself needs to be treated as a metric. Think of it this way, if you don’t get enough budget to cover the areas you know need attention then there will be gaps that are directly attributable.

Sadly a lot of budget increases come about because something bad has happened. But this (the fact that something bad happened) means more work needs to be done. And yet we struggle with the necessary quantification. Ultimately we should pursue business aligned initiatives irrespective of the difficulty of trying to pin down an accurate budget.

All-Out Mean time to recovery (MTTR) – Imagine the absolute nightmare scenario that your entire organization is decimated somehow. Imagine you are brought back to the stone ages of bare metal and have nothing but a few back-ups to recover from. How long will it take you to get your organization back to an operating business? Some organizations are well positioned to recover from isolated incidents, like a ransomware event. My thought process is around something far more catastrophic.

I am not sure there is an organization on the planet that can answer this question at breadth and depth. I fear that there is also a lot of hubris around this subject and some may feel this is not a situation they need to account for. The more typical all-out scenarios you may encounter focus on operational areas. For instance if all servers become unusable there is a DR plan that has been designed, tested, and tweaked to reach acceptable MTTR.

From a positive vantage point, the very act of trying to measure some of these admittedly challenging areas of operation will likely reveal many areas of improvement. That in and of itself may prove valuable to your organization in the long run. There are so many more we could come up with but the areas presented here are a decent starting point.

On the negative end there is an enormous challenge in that board and the C-Suite might not understand these metrics. Hell, I can think of many IT leaders that wont understand some of them. But these are not reasons to shy away from the challenge of educating folks. I understand the notion, and am a practitioner, of talking to the board on their terms, in their language. But is it truly beyond their capabilities to understand some of these points? Is it unreasonable for us to push for a deeper level of understanding and interaction from the board and the C-Suite on these metrics?

One suggestion is to be super consistent in the metrics you choose. By consistent I mean stick with them and show changes over time. The changes can be negative, thats ok. No one is delusional enough to expect total positive momentum all the time. Your presentation, of the metrics you choose, will be an investment and in time the board and the C-Suite will start to see the value, and that you are one persistent individual.

Ultimately, there are many superficial security metrics that keep you in a safe zone. I challenge all of us, myself included, to do better and be more creative. This will be difficult but I find it is well worth it. The outcomes may surprise you and the ancillary benefits (areas you will be driven to address, etc) may as well. There will of course be push back that these are difficult to understand. Or maybe the arguments revolve around the effectiveness of the message to the board and the C-Suite. But the fact that something is difficult is no reason to not tackle it.

Real cybersecurity or the pursuit of the optical illusion?

Are we always pursuing real protective measures? Real cybersecurity or the pursuit of the optical illusion? It is Q2 of 2022, somehow there are corporate leaders (executives, board members, etc) that still don’t take cybersecurity seriously. As a result they are not interested in security (i.e. a mature program, actual protective mechanisms, etc) but are instead satisfied with the illusion of it. They want to invest the least possible in this area and yet have the best results.

I find this a fascinating, and disturbing, dynamic. In fact, I don’t understand how this is even possible given the reality of todays corporate environments. A number of SEC proposed rules have made it abundantly clear that this needs to change. Moreover, the mainstream media coverage of cybersecurity related issues is very real. This alone should have cybersecurity as an “in your face”, “top of mind” area of concern. It is an area directly linked to the survival of most modern-day businesses. And yet, some corporate leaders still see it as overhead, not worth great investment because it is difficult to link it to revenue generation.

In thinking about this I can’t help but to link this to some of the horrible strategies I have run across over time. Subsequently, there is a message to corporate leaders here, the formula is simple. You get what you pay for. It is delusional to expect stellar results on a shoestring budget. Furthermore, we are here to protect the company, its people, its assets, we are not the enemy. Often we are perceived as such because these folks are just protecting the dollars and cents. Security hurts. And it costs money.

Humorously thinking about this situation, look at this image and ponder the actual reality it portrays:

Source: https://twitter.com/dimitrimckay/status/1513857312947114000/photo/1

The other humorous point to me is based on the introduction image at the top of this blog. The person trying to hold back the wolf clearly represents the corporate leaders I am writing about. Together with this the wolf represents those attackers we are sure to face at some point in our cybersecurity leadership journey. The formula is simple and the outcome is obvious.