Welcome

Skeeter Spray is a blog for the common Information Security Professional. Why Skeeter Spray? See Post #1

Monday, October 24, 2016

Getting Security Buy-in from Everybody

Buy-in of Information Security projects / initiatives / “we should just be doing it” is a tricky thing.   While support from senior leaders in the organization is key for resources (i.e. $$$$) and using their name in vain (i.e. “this is a top priority of Mr. Big Pants” or “this project has the visibility of the Mrs. Big Office”).   But other that the money and maybe telling their direct reports it is important, they really don’t do a lot for the execution of the project or initiative.

What we, the Information Security team, need is the support of the IT teams (Windows and Linux administrators, Identity Management, Application support teams, Network services, etc…).  These are the teams that have to do the bulk of the work to implement most of our initiatives and complete our projects.    But why doesn’t word get down to them that it is important?   Why aren’t they jumping up and down to help us?   Well, guess what?   They have other things to do.   Like their daily break/fix, updates, customer enhancements…. you know things like – their job.

So where does the solution fall?   I believe it is two-fold.  

First, IT is an expense center…organizations are running IT as lean as they can so there is very little extra bandwidth for projects and initiatives outside of their respective customer base.   Additionally, the same IT people can be Information Security’s forward security beacons.  The administrators know when something isn’t right on their system and maybe if they had a little more time, they would investigate it further and report it to Information Security.   So by know you are asking…. how can Information Security help this problem?  Information Security has the ear of senior leadership, include low IT manning as a risk on your report(s) to leadership (ensure there is some coordination with IT management first).

Second, build that relationship with the other IT teams and be sensitive to their plight.   Have regular meetings with the IT teams and let them know what is going on in Information Security.   If you have a project going forward, let them know early on what the expected impacts are to their teams.  And lastly, be careful when you play the “we brief Mr. Big Pant and Mrs. Big Office every month on the status of this” ….it won’t help the relationship.

Until next time….
~Skeeter

Wednesday, June 1, 2016

What Should Information Security Be Responsible For?

In the Enterprise environment it seems there is always a battle around who should be responsible for what in IT.  And there is always some manager or director that complains (or his people do it for him / her) that Information Security seems to be over-stepping their bounds.   Where is that boundary and where should it be?   The answer to both questions is it depends based on the organizational structure, expertise on different teams, and the culture of the organization.

A couple of areas that always seem to come up are email and network security controls.  Let’s look at email first.  No information security team wants to be responsible for working tickets about emails that weren’t delivered or restoring mailboxes.   These activities should reside with an email team.   However, who should control the settings on the mail scanner and what is or isn’t allowed through?   I believe that regardless of who does the actually setting of the security controls on the mail scanner, the Information Security team should be the final decision makers of what the controls are set too.  Since the Information Security team is the group that has the knowledge about the risks, vulnerabilities, and exploits, and they will be the group driving the Incident Response process, they need have the ability to make ensure that a defense in depth architecture is implemented.

Network services, specifically firewalls configuration control, is also an area of concern for many organizations.   I am all in favor of a Network team (whether they report to security or are separate) doing the wrench turning of the firewalls.   The security analyst should stay out of it if at all possible.   However, I believe that Information Security should be the approval authority for all firewall changes….rules, file types, even logging changes. 

There are other areas of IT, such as A/V – end point protection, identity services, workstation and server gold images, etc…. that also fall into the same category.   Information Security doesn’t need to do the day-to-day work, but they need insight, and in some cases, approval authority to changes.    It all comes down to one group knowing all aspects of the defense in depth strategy for and organization.

Until next time…
~Skeeter

Thursday, May 12, 2016

Is the problem local admin or change?

Welcome back. "...back after {an} exclusive three year tour of Europe, Scandinavia and the sub continent" (Cab Calloway in the Blues Brothers). Ok, not really, I never left the city for more that a week at a time and that was for training. However, you may be asking yourself, where has Skeeter been? Well, it is a long story. But the cliff note version is a new job, completing my Masters degree, and earning several certifications. Now I am back to pondering Information Security thoughts in my blog. Hopefully on a more regular basis.

Today's topic is local admin on workstations or maybe just the process of change. An organizaiton has allowed users to have local admin on their respective workstation forever. But the world has changed and security controls need to be implemented. So, why is it so hard to take local admin away? It shouldn't take months and months of planning and then talking, and going back an forth. Why doesn't management get it? Is it just that people don't like change?

It should be as easy as send out the change message to the stakeholders, let them know how it affects them, why it needs to change (and how it protects them by changing), what the exception process is, test what needs to be an exception, and then GO.

I figure that 80% won't know that they lost local admin privilges -- 20% to deal with. Of that 20%, half will want it back, but don't have a business justificaiton for having it and therefore won't have the balls to submit the exception request. That leave just 10%, they probably need it at some point and time, but maybe not all the time. For those that do need it all the time, I am ok with them keeping it (for now and until we address that in another project). For those that only need it occasionally, we have a technical solution developed for them to contact their desktop support person and get it for a limited time.

Thanks for listening to the rant and until next time...

~Skeeter