Training, Acknowledgements and Awareness

In my previous post, I provided some information to help you get your Security Policy (the policy) communicated to employees, ensure the policy works for your organization and enforce it.

Today, I’m going to leap forward a bit and provide information to help you not only enforce the policy, but ensure employees are actually reading and understanding the policy.  Doing so, follows security best practices and can even help you become compliant with many industry standards.

First, you should create a list of the items in the policy, which are important to your organization, for example:

• User name and password requirements (format, length, strength, etc.)
• Physical security requirements (access to sensitive areas and information, tailgating, access cards, biometrics, etc.)
• Logical access (how access is approved, assigned, tracked, and audited)
• Software use (licensing requirements, copying, support, etc.)
• Remote access (authorization, VPN applications and use, authentication, etc.)
• Visitor policy (NDAs, visitor badges, access, use of non-company equipment, etc).
• Monitoring and use of company assets (Internet, chat, e-mail, etc.)
• Incident handling (identification, notification, follow-up, etc.)
• Exception (notification, approval, tracking, etc.)
• Information classifications (private, public, internal use, etc.)
• Intellectual property (patents, trademarks, etc.)

The above is not intended to be a comprehensive list, but rather a high-level suggestive list of items an organization may want to focus on.

Next, develop a set of questions (e.g., multiple choice, true/false, or combination thereof, etc.), which highlight the topics you selected. You don’t want to make the questions too difficult, but at the same time, should be worded in a way, which requires the user to read the policy to be able to answer them. 20 to 40 questions should be sufficient to ensure your employees have read and understand the policy. Set the passing grade (e.g., 90% or whatever you choose) and those who do not pass, have them find those items in the policy and correct their answers. This will help them to understand those items they may not have read close enough the first time through.

You should also develop a short letter of understanding and acknowledgement, which states the employee has read, understands, and agrees to follow and enforce the policy on a daily basis. Have them sign the letter and file it in their human resources employee file (e.g., hardcopy or electronically).

You should have all your employees go through the review, test, and acknowledgement process on an annual basis. Even executive-level employees should be required to go through the process. Their participation not only enforces the importance of the policy, but also provides them with the knowledge to answer questions their reports may have about the policy.

Note: You can make the process described above part of your new hire procedures and before you assign equipment, physical and logical access, etc to a new employee, make them complete the review, test and acknowledgement. This helps you be proactive about security and sets the tone straight-away about the importance of protecting company and customer information.

Finally, you should take the list of topics you used in the test and develop a simple PowerPoint security awareness presentation, which you can make available to employees on the company Intranet, etc. This allows you to send quarterly (or whatever frequency you want) reminders to review the training; thereby checking another box for compliance.

If you create a program with the elements I’ve described herein, you are well on your way to having a solid Security Policy program.

Top Ten Sections in a Security Policy

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.

Smartphones. Phones. Cloud Based Services. Mobile security. Enterprise Security. All these topics are converging at an extremely fast pace. So fast a pace that the first four are outstripping the ability of the last in the list to keep up. Depending on which analyst report you look at, Smartphones account for roughly 20 % of the current cell phone market with estimates saying that by 2012, that number will hit 50%. If the trends and numbers hold true, Enterprise Security concerns and issues are likely to become bigger even faster.

So what's the concern? All the OSs (iOS, RIM, MS, Android, Sybmian, WebOS, etc.) offer similar degrees of what they call support for "Enterprise Security". This includes features like Remote Wipe, Security Policies, Data Encryption and so on. These devices are secure if your IT department deems them so. Not so fast! There is not a lot of information about platform security and companies don't have time to evaluate every OS to see if its platform architecture is secure enough for their data. Even if they wanted to, there is very limited data on this subject anyway. Look at Android, for example. Just this week two reports illustrated the dilemma of companies trying to support end users buying the latest and greatest tech, while making sure that their own company information, which might be integrated to that device, is still secure.

The first is a report from security firm SMobile Systems, which shows that a large percentage of apps in the Android Market have the ability to perform actions with permissions that most would deem sensitive. They estimate 20% of all apps analyzed request access to private or sensitive information. That's kind of scary. Even scarier is the statement that 383 current apps have the ability to "read or use credentials from another service or application". Read that again. Now ask yourself, if your company is putting your data into a Smartphone, and random Apps can "potentially" access that data, does this sound like a good thing? If the C in the CIA triad (Confidentiality, Integrity and Availability) is jeopardized based on any app an end user decides to download, how do companies push data to these devices in a secure fashion?

Google has already responded, saying that: a) all Apps must get users' permission before the app can access sensitive information b) Google performs billing background checks to confirm developer identities and c) any App that is deemed malicious can be remotely wiped from all phones in mass to prevent widespread damage. 

That's all well and good, but: a) Do users really understand what permissions they are granting an app when they run it, or what that App is going to do with the information it gets? b) Nice thought to check their "billing background", whatever that is. Yet it doesn't deter a developer from submitting a malicious app, or having a developer fake credentials like we've seen with several malvertising campaigns in the past, or just from something sloppy getting in and c) By the time they find out an app is malicious and remote wipe the app the damage is done.

Take for example Google recently wiping two apps that were created by security researchers that misrepresented their purpose. If they had been malicious in nature they might have been able to do serious damage. It seems that Google vets the devs, but not the app. Next time it could be a malicious developer writing a cute game that steals information off your phone.

I really don't mean to pick on Google; maybe iOS, MS, or WebOS sandbox their apps and permissions differently and are inherently more or less secure. Maybe iOS, with their restricted multitasking API, is more secure because it restricts their apps to only certain functions. Maybe iOS apps are more secure because Apple has a more stringent App review process, opposed to Google's Open Source system. Nonetheless, we are in a day and age where phone and cloud services are increasing at break neck pace, and new OS versions are constantly being released (hello iOS4 and Froyo). You have to wonder: when will touted "Enterprise Security" features stop being enough criteria for companies deciding which platforms to support? When will the base security in the Smartphone OS become understood well enough that companies will only allow certain certified platforms on their network?

 

Earlier this month RSA (the Security Division of EMC), with the help of the SANS institute, released the results of two new research studies to understand the log management priorities for mid-sized organizations. Even though event correlation and log management solutions by themselves have been receiving much needed attention lately, it was interesting to learn how organizations rated the reasons for using SIM/SIEM type solutions when compared to compliance standards and regulations.

Both studies found that security detection and prevention of unauthorized activities was ranked highest as a critical issue. I found this is to be somewhat surprising since the biggest business drivers and objectives for deploying such solutions seem to be regulatory requirements and compliance. Do you believe that this is true even for your organization? Use the comments section below to discuss.

In my experience, working with various Fortune100 to SMB type organizations, detection and prevention are definitely the desired byproducts of such solutions. Whether it really happens or not, depends entirely on the implementation strategy. There are two main schools of thought for deploying log management solutions to arrive at this point. In-house or Managed.

More often than not, requirements gathering and product selection criteria are instrumental to a successful execution plan. Many organizations still believe that acquiring 3rd party products to be operated and managed by internal staff is the only way to do it, but this is simply not true. In fact, this is also the main reason why many deployments are used only as a checkmark on compliance audits. There are many companies like Solutionary that offer managed log aggregation and event correlation solutions where organizations are only responsible for providing some basic space and connectivity in their data centers.

Here are a few factors that can help you decide what type of solution fits your organization better:

• Skilled Resources - While it may be more desirable to have the in-house IT staff review the logs and manage the solution, it is not always the most cost efficient way. Dedicating two or more trained employees to caring and feeding of the log management solution is certainly not possible for every company. Consider staffing this role in a very active operational environment, 24 hours a day, 365 days a year. You can quickly reach staff requirements for a dozen or more employees.
• Compatibility - Most good solutions available in the market, in-house or managed, pretty much support the same list of systems and devices. The bigger question organizations should ask during the selection process is - how easy (or difficult) is it to add a new log feed for a custom application or a previously unsupported device?
• 24x7x365 Monitoring - If detection and prevention of unauthorized activities is truly one of the goals, then it also help to ask if internal staff can support the solution at "all" times, but make sure you plan for nights, weekends, and holidays.
• Total cost of ownership - From a business perspective, this probably is the most important measure to help make the decision. Besides the true hardware cost, software costs, license fees and maintenance costs, the cost of square footage, power, networking, organizations should factor in the administrative, training, and other incidental requirements like cost of a creating a custom report for compliance, adding a custom application, etc. (Click here for an overview on Solutionary's IT security solutions without capital expenditures.)

I'd like to hear stories (successful or otherwise) on log management solutions that you were a part of. Please share some tips or experiences that might help your fellow security processional make the right choice.

We hear about security issues, alerts and problems every day. If you are anything like me, one of the things you want to know is "how bad is it really?" I won't talk about how often these security issues occur, but below are a few security conditions that seem reasonably representative of the types of things I have seen from my clients during just a few years in the industry. These are by no means the worst - I probably can't really talk about those. Names have been changed to protect the innocent.

1. A 1997 intrusion test (appropriately contracted) against a state agency found a path routed around their external firewall. The path was set up so that employees could reach internal systems, since, surprisingly enough, the firewall blocked such access. A 1998 test found the same path, as did subsequent tests in 2000 and 2002. A short time after the fourth test they had a breach of thousands of records, including very private employee and public information.

2. A major retailer's single server hosting their website (including the multi-million dollar online retail portion) was located under a desk in the IT area. There was no UPS, the Ethernet cable running across the hall was duct taped to the carpet, and offline backups were done to writable CDs (when they were done at all).

3. A distributed manufacturing company ran a Just-In-Time process. They posted weekly orders to remote manufacturing sites, and the remote sites were supposed to manufacture exactly what was downloaded. However, remote employees were taking up so much bandwidth browsing porn through the headquarters link that the order databases were not getting transferred, resulting in the distributed sites running at about 30% of capacity - meaning they were sitting idle for the better part of 2 days per week. They missed order points for three months and lost millions of dollars in revenue before they discovered why their orders were going unfilled.

4. A major international retailer had an externally available test environment run by their marketing department (I never did figure that one out). Since all systems still had their default passwords, unlimited network access into the core network for their World Headquarters was easily reached - even behind their internal firewalls. From there, it was simple to log onto distributed store systems and change local prices in all of their stores. $1.37 widescreen TV anyone? (Just kidding!).

5. A large energy company hired Solutionary to perform an intrusion test against their corporate web presence. As part of the test, they gave us their external IP address ranges to test. When we validated these IPs we found that they had also given us the IP range that covered their major competitor. I'm sure that was an accident, right?

6. A major manufacturer located their DR site at the eastern end of the same facility that housed their main data center on the western end of the same facility. The two facilities were located less than 300 yards from each other, were both on the same flood plain, and both in a known tornado zone. And, less than 100 feet outside the DR site wall was a gas station with a huge propane tank. To top it off, directly south of the DR site and up the hill was the community's largest water tower.

7. A major telecommunications company decided to add UPS support to one of their data centers to help protect against the consistent brown-outs the local power company was so kindly providing them. They installed a UPS made up of three computer racks of batteries and placed the units next to each other; neglecting to use a load-bearing support beam. The heavy racks warped the floor so thoroughly, that if a marble was laid on the floor near the computer room door - some 60 feet away from the UPS - it would accelerate across the floor and come to rest with a sharp "crack" at the front of the UPS.

So, if you recognize any of these, I apologize. But for the rest of you: do better, or I shall taunt you once again.

P.S. - There has been a lot of hype recently regarding the iPad security breach. Check out my article in USA Today where I discussed how the breach occurred.

Salutations pop culture and security lovers!  Do you remember the old episodes of Star Trek where they used a "Universal Translator" to communicate with alien life forms? In fact, they spoke into a small, hand held device similar to a microphone, and the device performed the two way translation between human and alien on the fly. I specifically remember the episode where Captain Kirk communicated with an alien that was in the form of a gas cloud. As it turned out, the translator portrayed the alien voice as a woman. Cool.

If we transport back from the distant future to the present, you may ask yourself, what this has to do with data security. The point is that there is no industry standard "language" for logging and sending security events to be processed by security folks such as ourselves.

Same Message, Different Alien

A perfect example of this would be how different IDS/IPS manufacturers format and log a SQL Injection security event. The event message IDs and descriptions from each vendor are all different; however they all are referring to the same common event, an "SQL Injection". Another example is the way a UNIX-based server logs a failed login attempt, as opposed to how a Windows-based server logs a failed login attempt. In either case, they look different, but they are both the same event type of "failed login attempt". From a security event analysis perspective, the sooner you can understand the meaning of each event type in a client environment, the better.

Enter the "Universal Translator" of Security

We have solved this event translation issue through the use of what we call "Solutionary Common Events" or SCEs. We map similar events from disparate devices to Solutionary Common Events (SCEs), which automatically correlate during event processing. This allows us to perform cross-correlation of events between unlike devices thus increasing our awareness into the client environment. This same translation technique is applied to all device log sources including firewalls, IDS/IPS, Web servers, applications, operating systems, databases, as well as network layer devices.

Most recently, we have been able to apply this technique into the healthcare vertical market in the form of Healthcare Privacy Monitoring Services. The same issue applies to Electronic Medical Record (EMR) application monitoring as it does for security device and server monitoring (different log formats and event descriptions).

For example, by applying ActiveGuard and SCE translation, we are able to track access to patient data across:

• Applications
• Systems
• Facilities
• Practices
• Remote users
• Partners

The key in this is to employ a "Universal Translator", in the form of an SCE, on all these different event types, and in turn provide security and compliance value to the client.

Live Long and.........

I could use some sci-fi cliché to end this post, but instead I'll just say, ride safe, crank up the tunes, and stay secure!