Tag Archives: risk

May 24 2023
1 Comment
Blog Posts

Dancing with the Cloud

Recently, I’ve written about the dangers posed by technology fallacies and one of the most frustrating for me involves discussions of “best in class.” In my experience, this mindset causes technology teams to get themselves wrapped up in too many pointless discussions followed by never-ending proof-of-concept work all in search of that non-existent perfect tool. The truth is that most organizations don’t need the best, they need “good enough” so they can get on with business. But this delusion has more serious consequences within the cloud. When you choose tools solely based on the requirement of being “best in class,” you could compromise the integrity of your cloud architecture. Without considering the context, your selection could violate a sacred principle of data center design – minimizing the size of a failure domain.

For many, cloud’s abstraction of the underlying network reduced complexity in what often seemed like arcane and mystical knowledge. It also allowed development teams to work unencumbered by the fear of seemingly capricious network engineers. However, the downside of infrastructure-as-a-service (IaaS) is that this same obfuscation allows those without a background in traditional data center design to make critical errors in fault tolerance.  We’ve all heard the horror stories about cloud applications failing because they were only located in a single availability zone (AZ) or region. Even worse, partial outages that occur due to application dependencies that cross an AZ or region. While this could still happen with physical data centers, it was more obvious because you could see the location of a system in a rack and your network engineers would call you out when you didn’t build in fault-tolerance and thwarted their planned maintenance windows.   

Today, it’s also common for organizations to use a variety of software-as-a-service (SaaS) applications with no knowledge of which underlying cloud providers are being used or how those services are designed. While this simplicity is often beneficial for the business because it increases velocity in service delivery, it can also create blind spots that violate the same failure domain principles as with IaaS. Only the most persistent technologists can unmask the inner workings of these applications to determine how they’re deployed and whether they align with their organization’s infrastructure design. Unfortunately, the business doesn’t always understand this nuance and can fall prey to the “best in class” fallacy, leading to brittle environments due to large failure domains. By exchanging their on-premise, sluggish systems for SaaS, the organization often accepts a different set of problems associated with risk.

Ultimately, when choosing capabilities, it’s a better recommendation to “dance with the cloud that brought you.” Instead of worrying about “best in class,” you want to select the technologies that are closer to your infrastructure by leveraging the services of your cloud provider where feasible. This translates to a better technology architecture for your organization because the cloud provider is making sure that their managed services are low-latency, resilient and highly available. While it may not always be possible, by taking the failure domain principle into consideration during the selection and implementation of solutions, you’ll achieve better service delivery for your organization.

Tagged , , , , ,
Jun 04 2016
Leave a comment
Blog Posts

Fixing a Security Program

I’m still unsettled by how many security programs are so fundamentally broken. Even those managed and staffed by people with impressive credentials. But when I talk to some of these individuals, I discover the key issue. Many seem to think the root cause is bad tools. This is like believing the only thing keeping you from writing the Next Great American novel is that you don’t have John Steinbeck’s pen or Dorothy Parker’s typewriter.

In reality, most of the problems found in security programs are caused inferior processes, inadequate policies, non-existent documentation  and insufficient standards. If buying the best tools actually fixed security problems, wouldn’t we already be done? The truth is that too many employed in this field are in love with the mystique of security work. They don’t understand the business side, the drudgery, the grunt work necessary to build a successful program.

For those people, here’s my simple guide.  I’ve broken it down to the following essential tasks:

  1. Find your crap. Everything. Inventory and categorize your organization’s physical and digital assets according to risk. If you don’t have classification standards, then you must create them.
  2. Document your crap. Build run books. Make sure you have diagrams of networks and distributed applications. Create procedure documents such as IR plans. Establish SLOs and KPIs. Create policies and procedures governing the management of your digital assets.
  3. Assess your crap. Examine current state, identify any issues with the deployment or limitations with the product(s). Determine the actual requirements and analyze whether or not the tool actually meets the organization’s needs. This step can be interesting or depressing, depending upon whether or not you’re responsible for the next step.
  4. Fix your crap. Make changes to follow “best practices.” Work with vendors to understand the level-of-effort involved in configuring their products to better meet your needs. The temptation will be to replace the broken tools, but these aren’t $5 screwdrivers. Your organization made a significant investment of time and money and if you want to skip this step by replacing a tool, be prepared to provide facts and figures to back up your recommendation. Only after you’ve done this, can you go to step 6.
  5. Monitor your crap. If someone else knows your crap is down or compromised before you do, then you’ve failed. The goal isn’t to be the Oracle of Delphi or some fully omniscient being, but simply more proactive. And you don’t need to have all the logs. Identify the logs that are critical and relevant and start there: Active Directory, firewalls, VPN, IDS/IPS.
  6. Replace the crap that doesn’t work. But don’t make the same mistakes. Identify requirements, design the solution carefully, build out a test environment. Make sure to involve necessary stakeholders. And don’t waste time arguing about frameworks, just use an organized method and document what you do.

Now you have the foundation of any decent information security program. This process isn’t easy and it’s definitely not very sexy. But it will be more effective for your organization than installing new tools every 12 months.

 

Tagged , , , , , , , ,
Jul 01 2015
Leave a comment
Blog Posts

Mythology and the OPM Hack

Seems like every security “thought leader” on the planet has commented on the OPM hack, so I might as well join in.

Although the scope of the breach is huge, there’s nothing all that new here. In fact, it’s depressing how familiar the circumstances sound to those of us who work as defenders in an enterprise. For the moment, ignore attribution, because it’s a distraction from the essential problem. OPM was failing security kindergarten. They completely neglected the basics of rudimentary security: patching vulnerabilities, keeping operating systems upgraded, multi-factor authentication for accessing critical systems, intrusion detection.

Being on a security team in an organization often means that your cries of despair land on deaf ears. Much like a mythical figure named Cassandra. She was the daughter of the Trojan king Priam and greatly admired by Apollo, who gave her the gift of prophecy. When she spurned his affections, he converted the gift into a curse. While her predictions were still true, no one would believe them.

As a recent Washington Post story reminded us, many in security have been predicting this meltdown since the 90’s. Now that IT has become a critical component of most organizational infrastructures, there’s more at stake and we’re finally getting the attention we’ve been demanding. But it may be too late in the game, leaving worn out security pros feeling like the Trojan War’s patron saint of “I told you so’s,” Cassandra.

Cassandra on TVM

Tagged , , , , , ,
Mar 01 2015
1 Comment
Blog Posts

Does IT Security Matter?

A few months ago I came across an article by Nicholas Carr called, “IT Doesn’t Matter.” It was published by the Harvard Business Review in what seems like the Paleolithic era of 2003, but I was shocked by its relevance. At the time, it caused quite a controversy with many mocking Carr’s predictions, but with ever-increasing outsourcing and the commoditization of compute, it seems even more relevant. If you’re working in any sector of IT today, then you’ll find many of his ideas shockingly prescient.

In the article, he manages to call out IT on it’s over-inflated ego, its annoying self-importance and tunnel-vision with regards to the rest of the business. Twelve years later, IT still manages to create an idolatrous following among staff, convincing senior leadership that it’s central to an organization’s strategy, even as it continues to fail the business.

It’s a reasonable assumption, even an intuitive one. But it’s mistaken. What makes a resource truly strategic – what gives it the capacity to be the basis for a sustained competitive advantage – is not ubiquity but scarcity. You only gain an edge over rivals by having or doing something that they can’t have or do. By now, the core functions of IT – data storage, data processing, and data transport – have become available and affordable to all. Their very power and presence have begun to transform them from potentially strategic resources into commodity factors of production. They are becoming costs of doing business that must be paid by all but provide distinction to none.

…as their availability increased and their cost decreased – as they became ubiquitous – they became commodity inputs. From a strategic standpoint, they became invisible; they no longer mattered. That is exactly what is happening to information technology today, and the implications for corporate IT management are profound.

However, the part of the article that really caught my attention was where he points out that IT actually increases organizational risk.

When a resource becomes essential to competition but inconsequential to strategy, the risks it creates become more important than the advantages it provides. Think of electricity. Today, no company builds its business strategy around its electricity usage, but even a brief lapse in supply can be devastating (as some California businesses discovered during the energy crisis of 2000). The operational risks associated with IT are many – technical glitches, obsolescence, service outages, unreliable vendors or partners, security breaches, even terrorism – and some have become magnified as companies have moved from tightly controlled, proprietary systems to open, shared ones. Today, an IT disruption can paralyze a company’s ability to make its products, deliver its services, and connect with its customers, not to mention foul its reputation. Yet few companies have done a thorough job of identifying and tempering their vulnerabilities. Worrying about what might go wrong may not be as glamorous a job as speculating about the future, but it is a more essential job right now.

Sound familiar?  Consider some of the recent breaches such as Target, Home Depot and Sony. This presents an odd contradiction, as IT becomes less relevant to business strategy due to its ubiquity, information security becomes more critical.

But Information Security will only deliver value if it understands context. I consider this as I recall recent conversations I’ve had with other security professionals in which they lament how misunderstood they are and how little the business appreciates what they do. The problem is that many don’t respect the people who generate the revenue allowing them to have jobs. Often they’re so busy focusing on the minutia of finding vulnerabilities and exploiting them, that they can’t pull back to understand that this only delivers value if it helps to reduce overall risk to the organization.

Tagged , , ,