Tag Archives: architecture

Sep 19 2015
Leave a comment
Blog Posts

Security Vs. Virtualization

Recently, I wrote an article for Network Computing about the challenges of achieving visibility in the virtualized data center.

Security professionals crave data. Application logs, packet captures, audit trails; we’re vampiric in our need for information about what’s occurring in our organizations. Seeking omniscience, we believe that more data will help us detect intrusions, feeding the inner control freak that still believes prevention is within our grasp. We want to see it all, but the ugly reality is that most of us fight the feeling that we’re flying blind.

In the past, we begged for SPAN ports from the network team, frustrated with packet loss. Then we bought expensive security appliances that used prevention techniques and promised line-rate performance, but were often disappointed when they didn’t “fail open,” creating additional points of failure and impacting our credibility with infrastructure teams.

So we upgraded to taps and network packet brokers, hoping this would offer increased flexibility and insight for our security tools while easing fears of unplanned outages. We even created full network visibility layers in the infrastructure, thinking we were finally ahead of the game.

Then we came face-to-face with the nemesis of visibility: virtualization. It became clear that security architecture would need to evolve in order to keep up.

You can read and comment on the rest of the article here.

Tagged , , , , , , ,
Sep 17 2015
Leave a comment
Blog Posts

Is Your Security Architecture Default-Open or Default-Closed?

One of the most significant failures I see in organizations is an essential misalignment between Operations and Security over the default network state. Is it default-open or default-closed? And I’m talking about more than the configuration of fail-open or fail-closed on your security controls.

Every organization must make a philosophical choice regarding its default security state and the risk it’s willing to accept. For example, you may want to take a draconian approach, i.e. shooting first, asking questions later. This means you generally validate an event as benign before resuming normal operations after receiving notification of an incident.

But what if the security control detecting the incident negatively impacts operations through enforcement? If your business uptime is too critical to risk unnecessary outages, you may decide to continue operating until a determination is made that an event is actually malicious.

Both choices can be valid, depending upon your risk appetite. But you must make a choice, socializing that decision within your organization. Otherwise, you’re left with confusion and conflict over how to proceed during an incident.

baby_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 , , , , ,
Jun 19 2015
Leave a comment
Blog Posts

Tootsie Roll Pop Security

Recently, it occurred to me that the security of most organizations is like a Tootsie Roll Pop. Hard and crunchy on the outside, soft and chewy on this inside. One bite and you easily get to the yummy center.

How many licks does it take to get to the crown jewels of your organization: your data?

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 30 2015
3 Comments
Blog Posts

Security and Ugly Babies

Recently a colleague confessed his frustration to me over the resistance he’s been encountering in a new job as a security architect. He’s been attempting to address security gaps with the operations team, but he’s being treated like a Bond villain and the paranoia and opposition are wearing him down.

It’s a familiar story for those of us in this field. We’re brought into an organization to defend against breaches and engineer solutions to reduce risk, but along the way often discover an architecture held together by bubble gum and shoestring. We point it out, because it’s part of our role, our vocation to protect and serve. Our “reward” is that we usually end up an object of disdain and fear. We become an outcast in the playground, dirt kicked in the face by the rest of IT, as we wonder what went wrong.

We forget that in most cases the infrastructure we criticize isn’t just cabling, silicon and metal. It represents the output of hundreds, sometimes thousands of hours from a team of people. Most of whom want to do good work, but are hampered by tight budgets and limited resources. Maybe they aren’t the best and brightest in their field, but that doesn’t necessarily mean that they don’t care.  I don’t think anyone starts their day by saying, “I’m going to do the worst job possible today.”

Then the security team arrives on the scene, the perpetual critic, we don’t actually build anything. All we do is tell the rest of IT that their baby is ugly. That they should get a new one. Why are we surprised that they’re defensive and hostile? No one wants to hear that their hard work and long hours have resulted in shit.

What we fail to realize is this is our baby too and our feedback would be better received if we were less of a critic and more of an ally.

Tagged , , , ,
Newer posts →