At Solutionary, we pride ourselves on customer service and support. In this business, that means we put ourselves on the line for our clients when things go bad. Incident response and coordination isn’t a cornerstone of our business, but it is something we do very well for our clients in a time of need. Unless your organization has an incident response program that is regularly exercised, it can be a little overwhelming when an incident is identified that indicates a breach has occurred.

When we get these types of calls, it isn’t because an employee has accessed inappropriate materials. It is because an IT administrator has been arrested for fraud or the company is undergoing a potentially brand damaging attack or data loss. Incidents that attack the brand can be as simple as web site defacement or as complex as getting targeted by an organized crime group, but in either case, it helps to have a friendly firm on your side to provide guidance when the breach is over.

One of the most significant challenges we face in supporting our clients is helping them to determine whether or not an incident constitutes a breach. To help make this determination, we coordinate resources to analyze the intelligence available. While in some cases a forensic image of a system may help, most of the evidence we need is contained in the log data produced by the systems that support the environment where the incident occurred. However, in many cases the log data is unavailable due to a failure to configure or retain the information properly.

We are not asking for a vetted set of log data that has been correlated and normalized by a SIEM (although that would be nice). We just want the raw log data. Without this information, it is almost impossible to determine with certainty that an incident resulted in a breach that warrants notification due to PCI, HIPPA/HITECH, or other compliance or legal requirements.

I encourage you all to review your log retention standards and capabilities to determine whether or not you maintain a minimum of 1 year of log data. Solutionary retains 100% of the raw logs we capture for our clients so they have forensically sound log data in their time of need.

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.

At this point you may find yourself asking, what does this have to do with data security? The other day I was doing a portal demo for a client and the gentleman mentioned he was rolling out iPads to some of his staff.

He was wondering if the ActiveGuard security and compliance portal supported the iPad browser. As it turned out we do in fact support the iPad interface with our security and compliance portal (Solutionary recently rolled out iPad support last month at the Gartner Security and Risk Management Summit). Now a client can be enjoying multimedia browsing, rock and roll, and still keep an eye on real time security event information. That is what I call freedom.

Given the recent high profile iPad security breaches I want to take the time to raise security awareness about protecting this new and popular endpoint. Recently my colleague Jon Heimerl specifically addressed this issue in a white paper titled "Endpoint Security and the iPad".

Check out Jon’s full paper when you get a chance. Until then, here are several tips to protect the iPad from a security perspective:

Physical Protection

It sounds like a no-brainer, but keeping the device (and all portables) as close to your vest as possible is always good. The old saying “out of sight, out of mind” applies here. This is especially true now when the iPad is ‘eye candy” to so many prying eyes.

Access Protection

It’s amazing how many folks do not enable passwords on these devices. A simple four digit pin is better than nothing, and could somewhat discourage a run of the mill thief. I know I even use simple 4 digit pins on the TV remote just to drive my kids crazy.

Logical Protection

This involves running some sort of anti-virus or personal firewall endpoint software on the device. Although applications of this type may not be widespread yet, you can bet the bad guys would love to infect America’s favorite new toy. If you think about it, this is a huge new attack surface that is growing larger every day.

Data Protection

Make sure you have enabled encryption whenever possible. Don’t forget to back up any personal data that may be stored on the device. Be especially careful to protect personal identifiable information of you and your loved ones. I for one am concerned about the thief of my portable device looking up my home address to plan for his next crime.

Communications Protection

If you use the iPad for communication to your corporate LAN, make sure you are doing so over some sort of encrypted link. This is especially a concern at airports, and other open Wi-Fi hot spots. The last thing you want is to be the target for a “man in the middle” type attack that could compromise sensitive data in transmission.

I would like to thank Jon Heimerl for his contribution to this blog. Until then, and as always, ride safe, crank up the tunes, and stay secure!

As we approach the end of the PCI Security Standards Council (SSC) “Lifecycle Process for Changes to the PCI DSS” and associated community meetings, many of my clients and colleagues are asking the same question: “What is going to change?”

In the case of my colleagues, the discussion is more sporting than anything else. However, in the case of my clients, the speculation regarding changes to the PCI DSS is causing some budgetary anxiety. This nervousness is mainly due to the fact that many organizations begin their fiscal year planning well in advance of the anticipated fourth quarter release. So the question remains: “what is going to change?”

Unfortunately, I do not have the answer to that question. Nontheless, I do think we can draw some inferences from the various comments that have been made regarding the coming changes, or lack there of as the case may be. Bob Russo, General Manager of the PCI SSC, is on record saying there would be no surprises in the 2010 update. Furthermore, the PCI SSC announced a new 3 year refresh cycle, which will lengthen the process for future changes. Based on these two pieces of key information and the emphasis on guidance documents, I believe that the card brands and the PCI SSC are giving the industry a chance to create solutions that will further mitigate the risk to card data.

Visa has been largely responsible for pushing the adoption of the PCI DSS into the payment industry. Maybe it is time for the payment industry to tackle the challenge of implementing the risk reduction solutions that are available. The payment industry should utilize the PCI DSS as a minimum standard of care and build control frameworks that exceed the requirements, or make them irrelevant. For example, Chip and Pin, End-to-End Encryption, Tokenization, and Virtualization all have the potential to exceed the requirements and reduce the risk to card data beyond that which is required by the Data Security Standard.

The PCI SSC has been gradually providing more and more rigorous guidance through both training and Implementation Supplements. Moving forward, the SSC will focus on continuing to tighten the screws through additional Information Supplements and training. This will reduce the overall risk to card data without the backlash that significant changes to the DSS would create.

Hope everyone is having a good compliance season. I'm looking forward to catching up at the Community meeting in Orlando.

Security – Freedom from danger or risk, or actions taken to prevent or decrease danger or risk. The quest for information security is a form of perpetual motion.

Secure – Nothing.

Insecure – Everything.

Privacy – An illusion.

Backup – What you wish you had done before your system crashed.

Social Media – Alternate communications media that supports socialization and promotes communications. Does not normally fall under the same level of control as "official" communications media such as email because of rapid adoption rates, informal communication formats, and immature controls and policies.

ROI (Return on Investment) – The amount you need to project as hopeful future savings to justify spending money on a project now. Sometimes also known as Rationalization of Imagination.

RGE – The result of a crash in your main data center that wipes out half of your corporate information because your DR site had never really been tested and was not working the way you needed it to. Also known as a “Resume Generating Event”.

Incident Response – Unless accompanied with planning, usually involves screaming, hair pulling, sobbing, and cursing, immediately followed by accusations of blame for some unwitting party. Often results in an RGE.

Cookies – What you bring the auditor to help make sure you pass your audit, since you had not been doing the right logging, or the right reporting, and you know you weren't really ready for them.

Disaster Planning – Planned, measured steps taken to help limit the negative impacts of a foreseeable disaster or other significant event before the actual event. See also "What BP didn't do".

Security Policy – What someone who does not understand your operations wrote down so that you could claim you had one.

TANSTAAFL – There Ain’t No Such Thing As A Free Lunch. It’s just a matter of when you pay for it in the end. And you always pay for it. Always.

Synapticurse – When you enter the command to restore the backup image, and you tell your finger to press the “Enter” button, the synapticurse is the physiological and psychological reaction you get in that fraction of a second after you realize you have reversed the parameters and will destroy your only backup, but it is too late for your synapses to fire the impulse to tell your finger to stop from actually pressing the button.

Blended Threat – That strawberry daiquiri you should not have had before you logged onto your work system to promote code to production.

SSID Roulette – The act of just picking one, when faced with that chaos of wireless networks that shows up in public or hotels where you never know which is the hotel approved wireless or which ones are the hostile, fake, access points that are waiting for you to connect for evil purposes.

Silver Bullet – That one security fix, enhancement, or product that can heal/prevent all security woes. Or, a projectile made of a pure metal used to kill werewolves. I mean, each one is just as likely as the other, right?

I saw this headline the other day: “Undersea cable set to boost West Africa broadband”.  My cynical, security-hardened mind fleetingly dwelled on the wonderful opportunity this presents to the academic and commercial sectors of Nigeria, before crashing headfirst into wondering what new cyber threats might emerge because of it.

Nigeria's penal code lent the “419” moniker to the class of scams that include deposed princes and government ministers with chests full of hidden cash, just waiting to be released with the kind help of a (greedy and ill-informed) stranger in a western country and their bank account details.

Given the level of cyber-activity we see on a daily basis from places in the world that combine good Internet connectivity, an educated populace, and a lack of local opportunity; it's no wonder that resourceful and clever Nigerians figured out a way to make the most of the cyber-cafes and their (relatively) limited connectivity.  Email represented an exceedingly cheap and bandwidth-conserving method of peddling their unique brand of cyber-crime.

What happens once the gloves are off and Nigeria joins Russia and China in having (for now at least) what must seem like unlimited high-speed bandwidth to the Internet?

There is a piece of legislation recently introduced in the U.S. Congress by Representative Zoe Lofgren that points towards a desire to ensure that the Internet does not become fragmented by countries that want to block access to "undesirable" sites or other countries. Of course, all the examples it cites are U.S. companies that it wants to protect from exclusion to markets.

While this is perhaps the empty (in the end) actions of the U.S. legislature, it does bring up the question of the ability and desire for nations to reflect politics and public policy via their connection to and forwarding of the Internet traffic within their borders; and the need to balance that desire with the intended or unintended consequences of doing so.

If this legislation is passed, it begs the question of whether any future action of the U.S. in blocking foreign sources of cyber attacks would be tenable politically.

It seems to me that we can't have it both ways.  Either we are for a free and open Internet and build defensive measures to protect ourselves when necessary, or we reserve the right to exclude geographic regions or specific sites deemed to disruptive and destructive towards the U.S. Internet network.

With Nigeria and West Africa being the latest to join the high-speed, high-bandwidth Internet community, we may want the option to respond appropriately in the event that the Russians and Chinese export more than just dams and power plants to the continent.

In the meantime, we will be keeping an eye out for emerging trends coming from the region in the next few months. I urge you to do the same.

We tend to get pretty busy around here. Sometimes, it almost feels like even I have a hard time keeping up with all of the new releases and updates. Almost. To that end, I will be periodically posting new Solutionary news and updates to make sure you, our valued readers and customers, are on the same page. 

To start with, here are a bunch of product updates I want to share:

- We have launched a new Visibility Services page for all our clients of the Visibility Service. You can now search, filter and review all your service alerts in a nice graphical interface. This is available via the Services -> Policy Management navigation bar.

- Visibility Service clients also now get a new "Open Services" report in the report generator - giving clients instant snapshots to their visibility service. To find this go to The Report Generator and select "Open Visibility Alert Summary" in the General section!

- We've added new Log Management audit reports for clients who need Log Management reports for compliance purposes. These reports snapshot the archive record, log date, File size and signature date and in the next two weeks a signature verification date will be added as well. These reports can be found under General reports in the report generator titled "Log Archive Report".

- New ActiveGuard Auto ticket rules are in final beta testing and should be ready in the next release! We've listened to those clients wanting this feature, and your wait is coming to an end! For all our SIEM clients you'll be able to leverage remote notifications now of security events in your environment.

- We're also in final beta testing of our new next generation vulnerability handling engine. The new engine allows clients much more functionality and more refined control, along with the added benefit of a having a more simple interface, as well as SOC integrated PCI lifecycle integration. More on that coming soon!

- And last but not least, we have a super slick Qualys API interface allowing clients the ability to view, and manually select which Qualys reports they want to load into the Solutionary ActiveGuard system for enhanced Threat Intelligence Correlation as well as for use in our own Vulnerability Lifecycle Management system.

Ok. Thats enough teasers and updates for now. Have a great week, everyone! 

From your friends at Solutionary!

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!

In my last post, I asked you where your organization sits in regards to a Security Policy. If you answered "We do not currently have a documented Security Policy", this post is for you. Below I describe, at a high level, the top ten sections you should ensure you include in your Security Policy. This information can also be helpful for those who want to either check, or beef-up, an existing policy.

Obviously, each organization's requirements will vary depending on the size of the company (e.g. number of employees, geographic locations, etc), nature of the business (e.g. manufacturing, retail, financial, healthcare, etc.), and compliance requirements for any applicable specific regulations or standards.

The information I've provided below is simply a rough outline of the top ten items and is not intended to be comprehensive. You will likely have a different outline once you've assessed the needs and risks for your organization, and that is just fine. However, I also suggest you include the points I identify below.

One more note before we begin: there is a lack of a separate Incident Response section due to the fact most organizations separate Incident Response into an entirely different document. If your IR plan is straight-forward and brief, you may want to include it within this policy as its own chapter or section.

There are many companies who can help you assess and develop a comprehensive Security Policy based on your organizations needs (yes, we can help you).

You should consider the following ten sections for your Security Policy:

1. Introduction
This section should describe why the policy exists, how and who is responsible for updating, maintaining, and enforcing the policy, and what is expected of employees in regards to following and enforcing the policy.

The policy should also describe the organization's security stance and mission for protecting company, client, and personnel information. A glossary of common or internal terms is also helpful.

Having the CEO, CIO, CSO or collective group responsible for the Security Policy (e.g. a Security Committee) endorse the Security Policy in a formal statement or letter (within the policy) is also important. At the very least, you will want to include some executive endorsement or support for the policy since this is not required by some security standards.

2. Overarching Policies
This section should define the roles and responsibilities of the organization regarding enforcement of the policy (e.g. Users, Management, Systems, Security Committee, etc.). Your overarching policies should describe how the organization manages compliance with the policy, including violations, reporting, and any disciplinary actions.

3. Information Security
This section should be very specific about how you classify public and private information (e.g. internal use only, restricted, confidential and proprietary, etc). This includes how to classify, declassify, mark, label and destroy such information.

This section should also include your determined level of protection for your sensitive information, including approved/authorized encryption.

Lastly, this section should detail intellectual property owned by the organization (e.g. patents, trademarks, copyrights, trade secrets, etc) and how to handle each type, including use of other organizations' intellectual property.

4. Personnel Security
This section should describe how the organization ensures the personal well being of employees, contractors, visitors, etc. This can include background check policies as well as how the organization protects employees' personal information.

5. Physical Security
This section should describe the organization's physical access controls (e.g. electronic cards access systems, video monitoring, security guards, etc). This section should also detail facility access for employees, visitors, vendors, contractors, etc. If you use a DVR, detail the organization's policy on monitoring, use and disclosure of surveillance video to the proper authorities upon legal request. 

It is important to also include details about visitor controls and the use of log books, visitor badges, restricted areas and restricted items, non-disclosure agreements, etc. You should describe your delivery and acceptance guidelines (e.g. company versus personal mail and package delivery, etc.) in this section.

6. Hardware Security
This section may fit within an overarching section for those with a relatively minor hardware inventory. However, if your organization has its own data center and utilizes a lot of different types of servers (e.g. security devices, media, etc.) you can make "hardware" its own section.

Use this section to describe how you administer your hardware (e.g., servers, desktops, laptops, firewalls, etc.). For example, do you allow employees administrator rights to their assigned machines? If the answer is no, you should describe in detail how you manage the installation of hardware and peripheral components.
You should also describe your inventory control process and return policies regarding employer property upon termination.

Describe in detail how employees can use employer property and the responsible parties involved with safeguarding the organization's assets.

7. Software Security
As with the hardware section, you may elect to incorporate this into another section if your software footprint is not significant.
This section should describe the software supported by the organization (e.g. operating systems, productivity software, proprietary software, etc.). You should document any internal software owned and developed by the organization and appropriate use and ownership of such software.

You should also describe, in detail, the appropriate use of copyrighted software and licenses, purchasing, auditing, reporting, and potential ramifications of non-compliance.

8. Information Access
Use this section to describe how access to company systems and resources (assets) is documented, approved, assigned, and controlled. You should describe how the use of systems banners and disclosure agreements are used to protect company assets.

Furthermore, you should describe your user, group ID and password policies as well as remote and wireless access restrictions and requirements. This is in addition to describing the proper use of authentication devices (e.g. bio readers, PINs, access cards, hardware tokens, etc).

9. Operations Security
If you monitor your employees web traffic or access to assets, you should include your consent to monitoring statement and language in this section. You should also describe how and when you utilize confidentiality notices (e.g. documents, e-mail footers, etc).

This section is also a good place to discuss the use of removable media (i.e., USB drives, cameras, mp3 players, smartphones, PDAs, etc).

Lastly, you should outline your session controls such as the use of screensavers and locking PCs while stepping away.

10. Exceptions
Let's face it, no policy is perfect; therefore, there will be exceptions. You should build a vehicle for which to request and report exceptions. This is an entirely different topic, which I may tackle in a future post.

Final Comments: Depending on how you structure your policy and how important communications are to your organization, you may want to consider a separate section for "Communications Security". This should include use and security surrounding telephones, cell phones, and smartphones, conference calls, meetings and conferences, facsimile, voicemails, and e-mail. You can also combine language about consent to monitoring and acceptable use of the Internet and Web browsing in this section, rather than have a separate acceptable use document.

I hope this information is useful to both those starting from scratch and those who just want to improve on an existing policy. Don't worry if your policy is brief when you are first starting out; something is better than nothing. Start with the items most relevant to your organization and build it as you grow.

Stay tuned for communicating, updating, and enforcing your Security Policy - and I promise the next post will be way shorter.