Implement, Communicate, Update, and Enforce Your Policy

My last post described how to develop a Security Policy from scratch. Some organizations may have a very basic policy in-place but do not communicate, update, or enforce the policy. This post provides some high-level direction on how you can get started.

Note: Most industry standards and regulations (e.g., PCI, SAS-70, GLBA, HIPAA, SOX, etc.), require you have, at a minimum, a written Security Policy that is communicated to employees, contractors, etc.

You do not need a committee to get started on implementing your policy. However, I would suggest a few very important administrative assurances before rolling it out:

• Technical Writer – have a tech writer develop, or at least, edit the policy
• HR Review – have HR review the policy to ensure it doesn’t conflict with your corporate culture or invoke an unnecessary burden to the company
• Legal Review – if an option, you should have a legal firm review the policy to ensure it is in line with local, state, and federal laws and regulations.

Implement

Once you have a Security Policy (albeit in many cases very basic), you can quickly take a step closer to compliance by implementing a few basic principals:

1. Require all new employees to read your Security Policy (or all employees if you are starting from scratch with a policy for the first time)
2. Notify employees of changes you make to the policy
3. State the disciplinary actions, which may result from non-compliance

Update

You should review the policy at least on an annual basis to ensure it is still valid, accurate, and applicable. You will always find there’s information missing or it is outdated.

Communicate

When you do make changes to the policy, ensure you communicate those changes via e-mails or the company Intranet. This will reduce the cycles involved with HR when employee’s question why policy has changed and they were not informed.

Enforce

Train employees on the importance of following the policy and the ramifications for not following it. Require employees to report any instances of non-compliance or incidents to your security officer, HR representative, or executive.

If you implement these basic principals, you are well on your way to having a solid Security Policy and program. Up next, I’ll discuss how you can take implementing your Security Policy to the next level and get you one step closer to a solid security program.

Salutations, pop culture and security lovers! I have always been intrigued with science fiction themes where machines serve man. Initially, the relationship seems to work well; both machine and man existing in harmony while getting their work completed. Of course the interesting turn of events are when the machines gain enough "intelligence" to determine there is no longer a need for the inferior humans. Let the carnage begin! This is especially true in the Star Trek and Terminator series. I also cannot fail to mention the film "2001: A Space Odyssey" and the main computer "HAL". HAL eventually needed to be deactivated after several attempts to kill the humans on the space mission. I love it when they request HAL to "rotate the pod" to see if the machine is listening as the crewmen conspire to deactivate the super computer.

 

 

 

 

 

HAL 9000

As usual, you may ask yourself, what does this have to do with data security? The point is that no matter how good the threat detection technology becomes (the machine), there will always need to be the human element that oversees and validates security events prior to alerting the client. The true value we [Solutionary] bring to the client is a combination of People (SOC Analysts and other support personnel), Processes (Implementation, alerting, escalation), and Technology (ActiveGuard) that all work together in concert to provide relevant, intelligent, security services.

Here are a couple of examples of threat detection to illustrate my point.

Spyware, Adware, Malware Detection

The following security event represents malware being detected on a client network. Malware can be inadvertently installed on client machines through many ways including the installation of 3rd party search bars, or news and weather bar applications on the desktop. Often times the malware infected machine will send usage or personal information back to a central collection server to be used later for malicious purposes. The analyst viewing the event queue determines that a single host is communicating outbound (using port 80) to hosts all over the world.

 

Figure 1: Spyware, Adware, Malware event queue view

Further investigation by the analyst confirms the infection by identifying the string "Relevant Knowledge" listed in payload decode. This is known to be a common type of spyware/malware footprint. The analyst would typically notify the client of the event, and recommend running the appropriate anti-spyware or anti-malware removal software to resolve the issue.

 

Figure 2: Spyware, Adware, Malware log line view

 

Additionally the Snort Signature that fired the alert is viewed. In this case, the specific spyware detected in the signature is identified as "Hijacker market score runtime detection". The snort signature specific content string is identified as "User Agent OSS Proxy". Notice the content string found in the Snort Signature is also present in the Decoded Payload. The analyst will compare the Decoded Payload with the Snort Signature to manually confirm this is not a false positive event.

 

Figure 3: Spyware, Adware, Malware Payload and Snort signature view

 

Acceptable Use Activity - Info VNC Remote Desktop Activity

The following security event represents an event where VNC (remote desktop) software usage is detected. Some clients authorize the use of remote desktop software for administrative purposes. However, other clients may prohibit the use of such software and therefore want to be alerted if this activity is detected. The analyst confirms VNC activity through the use of port 5900.

 

Figure 4: Info VNC event queue view

 

By viewing the log line detail, the analyst can view the Decoded Payload to further identify character strings associated with VNC activity. If this type of activity is acceptable for administrative purposes between specific internal users, Solutionary can create an ActiveGuard rule that will allow specific internal VNC traffic. Simultaneously, Solutionary can create an alert if VNC activity occurs between an internal host and an external host, for example.

 

Figure 5: Info VNC log line view

 

The bottom line here is that it takes humans to oversee the operations of machines to ultimately provide value to the client. Stay tuned for future security event detection examples from the real world. Until then, and as always, ride safe, crank up the tunes, and stay secure!