Monthly Archives: June 2016

Booth Babe Shame

Yesterday on Twitter I came across the following in my feed:

Screenshot 2016-06-23 13.46.05

I was horrified and angry, responding with the following:

Screenshot 2016-06-23 14.05.41

I also posted something similar on Linkedin, Facebook and Google+.  I never heard from the vendor, but I did hear back from some pretty offended men and women, both technologists and non-technologists.

Screenshot 2016-06-23 14.15.34

Why are we still having this conversation? Why would ANY vendor think it’s appropriate to make make the staff at a technical conference dress like employees at Hooters?

There’s a bitter irony in reading article after article about improving the diversity in STEM fields and then seeing this. I’m getting pretty tired of feeling like a second class citizen in this industry. I’d like to be able to go to a conference and know that I’ll be treated with the respect due a senior-level technologist, not minimized because I happen to have a uterus. Clearly, I’m not the only person who feels this kind of behavior is no longer acceptable and shouldn’t be tolerated. I encourage anyone equally appalled to call out the vendor in question. If we can’t appeal to their morals, maybe they’ll think twice if it impacts their bottom line.

UPDATE: I’ve been corrected regarding the venue. This event took place at a Vegas night club, but I’m STILL offended. I don’t see any Booth Bros. Why did this vendor feel the need to have women promote their product this way?

UPDATE 6/28: Looks like people at Nutanix are embarrassed, but I’m not sure if this will actually translate to any awareness on their part.

“In a blog post Friday, Julie O’Brien, vice president of corporate marketing at Nutanix, apologized for the stunt while also offering an explanation of what went wrong.”

This was in my feed this morning: Nutanix CMO After Risque Conference Stunt: I Will Resign If It Happens Again.

 

Tagged , ,

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 , , , , , , , ,
%d bloggers like this: