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

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

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

Threat Modeling and Security Assessments

Over the last several months, in creating a threat evaluation model / process and performing a security evaluation, I have come to several conclusions.

In creating a threat model, you must create a process that is repeatable, yet has some flexibility in it to meet different situations.  For example, evaluating threats and vulnerabilities against an operating system, such as what patches are missing, and what risk they bring to the current environment is different than evaluating a process for password management.  The threat model has to have some flexibility to ensure both cases are able to utilize the process.

The security evaluation of another company’s enterprise is more difficult that evaluating your own.    In my enterprise I know how management see risks in certain areas and I can gauge what the remediation effort will be based on the experience of working in my enterprise.  However, when evaluating another enterprise, is more difficult to know everything that may affect the risk score and remediation efforts.

Overall, the exercise was very good and a good bit of knowledge was gained.

Until next time…

~Skeeter

Creating an Action Plan from a Security Review

After all the work of performing a security review of an organization, it is time to create an action plan.   This plan must be something the client can use, so it must be.…..actionable.

How do you classify the threats and vulnerabilities that need to be addressed?   Do you do it by functional area, location, responsible area, severity, or by amount of effort to implement the recommendation?

I believe using a table format is the easiest to ready for the client.   Additionally, I believe breaking the table up by function area is also beneficial for the client.  I choose to list the deficiencies by risk level.  This allows the client to quickly identify the highest risk items for each section.  

The typical action plan table will have the following headings

Vulnerable Area/System - The area (Active Directory) or System (Checkpoint Firewall)
Threat Description - A short description of the threat / vulnerability.   The full description and/or risks will either be listed elsewhere in this report or in separate threat analysis report
Severity - The risk level of the threat...High, Medium, Low
Remediation Effort -  This is based on the amount of work that will be required to implement the specific control.  I prefer to use Costly, Moderate, Low.
Recommendation - This is the recommendation to correct the deficiency.  I choose to keep this at a high level, as details can be provided to each responsible area.

Finally, an appendix of definitions.  At a minimum it includes the definitions of the Risk ratings and Remediation Effort ratings.
 
Until next time....
~Skeeter

Threat & Vulnerability Mitigation – Asset Identification

No matter what you all your program (I call mine Vulnerability Management) to manage threats and vulnerabilities as they apply to your network and processing environment you must know what you have for assets. 

Assets ---equipment, operating systems, virtual environments, applications, infrastructure parts and pieces --- need to be identified by manufacture, make, model, version, etc...   While it will be a chore to initially identified and gather all the information of these assets; the hard part may be keeping the data current without proper processes in place.

When setting up the process to gather and keep the information current, keep in mind that it should be part of other processes.  For example, during the project phase for new systems, include a step to update the asset database.   Including a step in the change management process that requires an update of the asset database with the new information will ensure existing assets are kept current.

One of the items that is frequently forgot in the asset identification is the network infrastructure.  Don’t forget to identify the firewalls, proxy servers, VPN concentrators, switches, wireless equipment (switches and access points), and network management devices.   As a security professional, make sure you include your own systems, such as a SIEM, DLP, A/V and malware servers, and vulnerability scanners.

A key part of the tracking of threats against assets is knowing how the devices are configured and used in your environment.  An example would be Active Directory…what changes are made from the default configurations?   How does your password policy compare?   Is it weaker or stronger?   This could have an effect on the risk rating applied to a vulnerability identified for your operating system.

Once you have the assets of your IT environment identified, it is time to start down the identification of SCADA and other control systems…..good luck.

Until next time….

~Skeeter

How, What, and When to Patch

How an enterprise decides to manage patch administration probably varies based on who is doing it, the maturity of the Vulnerability Management program, and the business’ tolerance of maintenance windows.  In my opinion patching should be broken into four categories:

(1)  Infrastructure.  This would be servers, devices, applications that are used by IT and can be patched with no impact to business users or business processes.   This patching can be accomplished as often as necessary, but monthly will probably work out the best.

(2)  Servers / Operating Systems.  This category includes the Windows and / or Linux servers in the environment.  This is where IT management needs to get a recurring maintenance window from the business that is always available for IT to use whether it is needed or not.   In my humble opinion this window should be available weekly.   While we are probably not going to patch weekly, this windows can be used to fix application problems, apply emergency / critical patches, etc…   Server patching probably can’t be performed more that quarterly because you will need time to test patches in the non-prod environment.

(3)  Applications.   This category includes business applications such as ERP systems, HR systems, etc…   These systems should be patched during the maintenance window arranged by IT management above.  How often this patching occurs will depend on the business’ desire because it will take good amount of resources to test the patches and identify any impacts on systems that may feed or receive data from the patched system.   Twice a year maybe the best case scenario; once a year maybe the answer the schedule that works best for the business.

(4)  Workstations.  This is where the biggest risk may be located for the enterprise.  While the endpoint security (anti-virus, anti-malware, etc…) should be updating daily, OS patching should be applied monthly.  If a standard desktop image is used, testing should be pretty straightforward and a reboot by users once a month isn’t to much to ask.

No matter what schedule an enterprise decides on, the key is management buy-in and communications to the user community.   Once the schedule is set, stick to it and only deviate in rare and unique situations.

Until next time…

~Skeeter