Tag Archives: business strategy

Nov 29 2021
Leave a comment
Blog Posts

Compliance As Property

In engineering, a common approach to security concerns is to address those requirements after delivery. This is inefficient for the following reasons:

  • Fails to consider how the requirement(s) can be integrated during development, thereby avoiding reengineering to accommodate the requirement 
  • Disempowers engineering teams by outsourcing compliance and the understanding of the requirements to another group.

To improve individual and team accountability, it is recommended to borrow a key concept from Restorative Justice, Conflict as Property. This concept asserts that the disempowerment of individuals in western criminal justice systems is the result of ceding ownership of conflict to a third-party. Similarly, enterprise security programs often operate as “policing” systems, with engineering teams considering security requirements as owned by a compliance group. While appearing to be efficient, this results in the siloing of compliance activities and infantilization of engineering teams. 

Does this mean that engineering teams must become deep experts in all aspects of information security? How can they own security requirements without a full grounding in these concepts? Ownership does not necessarily imply expertise. While one may own a house or vehicle and be responsible for maintenance, most owners will understand when outside expertise is required.

The ownership of all requirements by an engineering team is critical for accountability. To proactively address security concerns, a team must see these requirements as their “property” to address them efficiently during the design and development phases. It is neither effective nor scalable to hand off the management of security requirements to another group. While an information security office can and should validate that requirements have been met in support of Separation of Duties (SoD), ownership for implementation and understanding belongs to the engineering team. 

Tagged , , ,
Jan 12 2018
1 Comment
Blog Posts

The Five Stages of Cloud Grief

Over the last five years as a security architect, I’ve been at organizations in various phases of cloud adoption. During that time, I’ve noticed that the most significant barrier isn’t technical. In many cases, public cloud is actually a step up from an organization’s on-premise technical debt.

One of the main obstacles to migration is emotional and can derail a cloud strategy faster than any technical roadblock. This is because our organizations are still filled with carbon units that have messy emotions who can quietly sabotage the initiative.

The emotional trajectory of an organization attempting to move to the public cloud can be illustrated through the Five Stages of Cloud Grief, which I’ve based on the Kubler-Ross Grief Cycle.

  1. Denial – Senior Leadership tells the IT organization they’re spending too much money and that they need to move everything to the cloud, because it’s cheaper. The CIO curls into fetal position under his desk. Infrastructure staff eventually hear about the new strategy and run screaming to the data center, grabbing onto random servers and switches. Other staff hug each other and cry tears of joy hoping that they can finally get new services deployed before they retire.
  2. Anger – IT staff shows up at all-hands meeting with torches and pitchforks demanding the CIO’s blood and demanding to know if there will be layoffs. The security team predicts a compliance apocalypse. Administrative staff distracts them with free donuts and pizza.
  3. Depression – CISO tells everyone cloud isn’t secure and violates all policies. Quietly packs a “go” bag and stocks bomb shelter with supplies. Infrastructure staff are forced to take cloud training, but continue to miss project timeline milestones while they refresh their resumes and LinkedIn pages.
  4. Bargaining – After senior leadership sets a final “drop dead” date for cloud migration, IT staff complain that they don’t have enough resources. New “cloud ready” staff is hired and enter the IT Sanctum Sanctorum like the Visigoths invading Rome. Information Security team presents threat intelligence report that shows $THREAT_ACTOR_DU_JOUR has pwned public cloud.
  5. Acceptance – 75% of cloud migration goal is met, but since there wasn’t a technical strategy or design, the Opex is higher and senior leadership starts wearing diapers in preparation for the monthly bill. Most of the “cloud ready” staff has moved on to the next job out of frustration and the only people left don’t actually understand how anything works.

AWS_consumption

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 , , , , , , , ,
Feb 25 2016
Leave a comment
Blog Posts

Fear and Loathing in Vulnerability Management

Vulnerability management – the security program that everyone loves to hate, especially those on the receiving end of a bunch of arcane reports. Increasingly, vulnerability management programs seem to be monopolizing more and more of a security team’s time, mostly because of the energy involved with scheduling, validating and interpreting scans. But does this effort actually lead anywhere besides a massive time suck and interdepartmental stalemates? I would argue that if the core of your program is built on scanning, then you’re doing it wrong.

The term vulnerability management is a misnomer, because “management” implies that you’re solving problems. Maybe in the beginning scanning and vulnerability tracking helped organizations, but now it’s just another method used by security leadership to justify their every increasing black-hole budgets. “See? I told you it was bad. Now I need more $$$$ for this super-terrific tool!”

Vulnerability management programs shouldn’t be based on scanning, they should be focused on the hard stuff: policies, standards and procedures with scans used for validation. If you’re stuck in an endless cycle of scanning, patching, more scanning and more patching; you’ve failed.

You should be focused on building processes that bake build standards and vulnerability remediation into a deployment procedure. Work with your Infrastructure team to support a DevOps model that eliminates those “pet” systems. Focus on “cattle” or immutable systems that can and should be continuously replaced when an application or operating system needs to be upgraded. Better yet, use containers. Have a glibc vulnerability? The infrastructure team should be creating new images that can be rolled out across the organization instead of trying to “patch and pray” after finally getting a maintenance window. You should have a resilient enough environment that can tolerate change; an infrastructure that’s self-healing because it’s in a state of continuous deployment.

I recognize that most organizations aren’t there, but THIS should be your goal, not scanning and patching. Because it’s a treadmill to nowhere. Or maybe you’re happy doing the same thing over and over again with no difference in the result. If so, let me find you a very large hamster wheel.

hamster_meme

 

Tagged , , , , , ,
Aug 07 2015
1 Comment
Blog Posts

Being the Security Asshole

Yes, I have become a security asshole. The one who says “no” to a technology. But I say it because of risk, and not just security risk.  And I’m angry, because my “no” is a last resort after many struggles with developer, engineering and operations teams in organizations that struggle to get the basics right.

I try to work with teams to build a design. I bring my own architecture documents and diagrams, which include Powerpoint presentations with talking points. I create strategy road maps explaining my vision for the security architecture in an organization. I detail our team’s progress and explain how we want to align with the rest of enterprise strategy and architecture. I stress that our team exists to support the business.

What do I get in return? Diagrams so crude, they could be drawn in crayon or made with Legos. They usually don’t even have IP addresses or port numbers. I have to argue with sysadmins about whether Telnet is still an acceptable protocol in 2015. I’m subjected to rehashed Kool-Aid about how some product is going to rescue the organization even though I found significant vulnerabilities during the assessment, which the vendor doesn’t want to fix.

And if this means that you hate me, fine. I’ll be the asshole. I’ll embrace it. But at least I can have a clear conscience, because I’ve done my best to safeguard the organization that’s paying me.

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

Are You There Business? It’s Me, Information Security

Are you there Business? It’s me, Information Security. We need to talk. I know you’re busy generating revenue and keeping the lights on, but we’ve got some critical matters to discuss. I feel like everyone hates me and thinks I’m a nag. Every time I want to talk to you about patching and vulnerabilities, I’m ignored. I’m so scared, because I’m always trying to secure the network so the bad guys don’t get into it, but no one wants to help me make sure that doesn’t happen. Honestly, I don’t feel heard. It seems like everything is about you all the time. I get it. I wouldn’t have a job without you, but I really need to feel respected in this relationship. Because let’s be honest with each other for once, if you’re breached, I’m probably the one that’s getting fired.

I understand that you don’t always remember passwords, which is why you write them down or use your pet’s name. I know that it’s takes a lot of time to follow rules that don’t always make sense. But this is important, so could you find a way to work with me?  I’d really appreciate it, because I feel so frightened and alone.

Yours Truly,

Infosec

P.S. Could you please stop using the word “cyber”in everything? I really hate that term.

P.P.S. And yes, I’m blocking porn because it really does have malware. But also because HR told me to. So please don’t get mad at me.i-wonder-if-9jgrq0

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

Meetings: the First Horseman of the Apocalypse

While browsing the Interweb for daily threat intelligence this morning*, I found an interesting research paper, “Meetings and More Meetings: The Relationship Between Meeting Load and the Daily Well-Being of Employees.” Anyone with some amount of seniority in IT is familiar with the concept of “death by meeting,” so I was excited to find scientific research (!) confirming that meetings are the soul-sucking creation of Satan.

Meetings are an integral part of organizational life; however, few empirical studies have systematically examined the phenomenon and its effects on employees. By likening work meetings to interruptions and daily hassles, the authors proposed that meeting load (i.e., frequency and time spent) can affect employee well-being. For a period of 1 week, participants maintained daily work diaries of their meetings as well as daily self-reports of their well-being. Using hierarchical linear modeling analyses, the authors found a significant positive relationship between number of meetings attended and daily fatigue as well as subjective workload (i.e., more meetings were associated with increased feelings of fatigue and workload).

No shit, Dick Tracy. Every morning I check my calendar with trepidation, wondering how much of my day will be wasted watching pointless Powerpoint presentations, the “jazz hands” of the modern workplace. How often will I be forced to feign attention as leadership drones on about strategy? Then I realized that civilization will not be destroyed by weapons of mass destruction or global warming, but with meetings. As T.S. Eliot said,

This is the way the world ends
Not with a bang but a whimper.

It seems appropriate to end with an xkcd comic on the topic.

Meeting from xkcd.com

*Who am I kidding, I was watching silly videos like “The Running of the Pugs.” I blame Adobe Flash, not just for being insecure, but as the harbinger of time-wasting.

Tagged , , , ,
Jun 18 2015
Leave a comment
Blog Posts

The Security Policy’s Bad Reputation

I had a disturbing conversation with a colleague last night. He told me that he didn’t believe in compliance-only, checkbox security, so why should he waste time on policies and standards? I almost blew a gasket, but because he’s pretty junior, I thought it best to educate him. The following is a summary of what I told him.

Security policies and standards are a foundational set of requirements for your engineering, development and operations teams. Without these boundaries, the entire IT organization floats aimlessly, buying solutions and implementing controls without rhyme or reason. Generally, only oblivious technologists design solutions without referencing policies and most engineers are begging for this guidance from their security teams.  Engineers aren’t mind readers, they just want us to tell them what we want: in writing.  Without policies and standards, the result is reactive inefficiency, because the security team becomes a chokepoint for every implementation.

Security policies help keep organizations ahead of the risk curve. It means that risk has been evaluated to some degree and a decision made (by someone) regarding the level an organization is willing to accept. Any security organization that wants to achieve some level of maturity will spend the cycles to develop its policies or suffer the consequences.

Developing policies and standards isn’t an easy process. Often the right stakeholders haven’t participated in the discussion, the documents are badly written, outdated or compiled by consultants with no organizational context. Moreover, policy debates often degenerate into arguments over semantics, but the how of getting this done isn’t as important as simply getting it done.

Ultimately, when security professionals don’t create and maintain policies and standards, they have abdicated their responsibility to the organization that employs them.

Tagged , , , , ,
May 25 2015
1 Comment
Blog Posts

Are You Trying To Improve Security or Just Kingdom Building?

I’m a huge Seth Godin fan. Technically, a marketing guru, but he’s so much more than that. His wisdom easily applies to all facets of business and life. A few days ago, I read a post of his, “But do you want to get better?”

…Better means change and change means risk and risk means fear. So the organization is filled with people who have been punished when they try to make things better, because the boss is afraid.

I wonder if Godin ever worked in Information Security.

Some days it seems as though the practice of Infosec is more about how it sounds and looks to outsiders and very little about actual reduction of risk. Most of the time, real improvement to an information security program doesn’t arise from exciting changes or innovative new tools. It often comes from making better policies, standards and procedures. It could mean that you really don’t need five extra staff members or a Hadoop cluster. Maybe it means you learn to operationalize controls, automate and collaborate better with your peers in apps and infrastructure. Worrying less about kingdom building and more about what helps the organization.

But this kind of change is a gargantuan shift in the way many infosec leaders operate. Often, they’re so busy cultivating FUD to get budget, they can’t or won’t stop to ask themselves, “Do I want to make it better?”

Tagged , , ,
%d bloggers like this: