The One Seven Two Zero Blog

NO CANCEL FEATURE ON THE SITE

Computer Vulnerability Management

How to Patch vulnerabilities and keep them sealed.

Time is the enemy of every security manager charged with patching.

Despite (or perhaps because of) vendors' attempts to release patches on regular intervals, enterprises are still racing to seal holes in their infrastructures. Every extra minute a system remains unpatched is another opportunity for worms, backdoors, rooters and Trojans to infiltrate the network.

The clock starts the day the vulnerability is announced and, in many organizations, never stops. We all know the basics of how to roll out patches across the enterprise, so why is success so elusive?

In many enterprises, patching is a messy, time-consuming process through which security teams must lab test new code before welding it onto production machines. The most common mistake is repeating the arduous process with each deployment rather than building a process that makes deployments successively easier.

Think Six Sigma: Every time you roll out a patch, look for obstacles and make adjustments that simplify the patchprocess for the current and subsequent cycles. Through continuous process improvement, you can better plan patch deployments; save time and money; reduce errors and disruptions; and improve overall security.

Know Thy Network

If your cycle time is a month and vulnerabilities are being announced at the rate of two per week, the math is working against you. By the time you make it halfway through your first cycle, there are four new vulnerabilities that need remediation.

Simply increasing the speed of patch deployments isn't the remedy. Effective and expeditious patch management is as much about planning as it is implementation. This is where asset management-knowing what's on the network-comes into play. Inventorying and mapping your assets give you the ability to prioritize patches and their installations. Target high priority and high-value assets, then stage the remaining systems sequentially.

But networks are dynamic environments; inventorying and asset management are continuous processes. Each time you do them, you learn more about your network and can adjust patching plans accordingly.

Inventorying assets involves various security tools, including vulnerability scanners such as Nessus, Internet Security Systems' Internet Scanner and eEye Digital Security's Retina; mapping tools such as Nmap and p0f; and patch-level detection software. Some vendors, such as Tenable Network Security, are adding OS fingerprinting to their discovery tools, allowing for the detection of devices and information about what OSes and services they're running. Many automated patching systems include network mapping engines and service/ OS discovery tools that list machine names, IP addresses, OS version, risk level, vulnerabilities and missing patches.

Scanning and discovery tools have different capabilities and degrees of accuracy-none is 100 percent reliable. False positives and false negatives, from misidentifying OSes to failing to identify vulnerabilities, are common among all devices. Best practice is to use multiple discovery tools to check and verify the results of other scans.

Your network scans will be more accurate and efficient in identifying vulnerable systems as your asset management becomes more comprehensive. This, in turn, will enable you to develop sound policies backed by management and strong operational agreements with business and IT support units. These will translate into quicker, less disruptive system scans and prioritized patch deployment.

Knowledge Is a Change Catalyst

The benefits of network discovery and asset management processes are multifold. Not only do they help you better plan patch rollouts, but they empower you to craft policies and architectural changes to improve subsequent patch deployments and overall network security.

Consider this: Devices that are intermittently connected to the network-roving laptops, partner and contractor servers, etc.-account for most of the systems missed by network scans and consequent patch deployments. Bringing them into the fold will dramatically improve your coverage and will enable the deployment of endpoint security products to check devices against security policies before allowing network connections.

An accurate inventory process will identify machines, OSes and services and give you the opportunity to standardize platforms and images. Reducing the number of accepted OS versions will simplify future patch rollouts since you will only have to test against future platforms. Enforcing standard images will reduce the chance that a patch will blow up a particular machine because of unauthorized apps or utilities.

When you have a better sense of what's on your network, you can rearchitect to both improve security and smooth out future patch deployments. For instance, after discovering that your financial databases are distributed across your network, you could use the asset management information to move them into their own subnet and protect them with a DMZ and IPS. That way, when a patch is released for those systems, you know where they are and that they need to be patched first.

With the way today's networks are put together, it's no wonder that worms spread like wildfire. Networks are often hastily pieced together with a business model, not security, in mind, leaving them wide open to attack. The defense-in-depth scheme will better secure your enterprise in the long run-and slow the vulnerability exposure clock.

Managing People and Patches

It only takes one patch deployment cycle to discover which departments cooperate and which stymie the process.

Welding shut security holes is as much about managing people as it is the patches. You need to develop lines of communications, cooperation agreements and processes for patch deployment. To security managers, it's a matter of utmost urgency, but to business managers-those who own different pieces of the infrastructure-it means lost production time as their servers are taken offline for reboots.

You need to build and formalize a working relationship by stressing to each department the importance of patching.

Security departments should set expectations and guidelines for patching across the enterprise. With historical data and a clear sense of ROI and the criticality of patching, you can create a system in which business units are required to install critical patches immediately; moderate patches during predefined maintenance cycles; and routine patches during periodic updates. Enlist business units to carry the burden of patching and make them accountable, enforcing requirements and maintaining standards through SLAs.

You can use the information gleaned from successful, as well as botched, patch deployments to show each uncooperative department how its delay in deploying a critical Windows patch lead to a worm infection that cost significantly more downtime and remediation than the patch would have cost. Because time and resources mean money to business managers, show them the cost of failure.

This will keep patching from disrupting critical, revenue-producing processes while engaging cooperation from business units to address immediate threats.

Validation

Deploying patches is only half of the patch management process, the other half is verification. Whether you're using patch management systems, automated tools like Windows Update or SUS, or manually installing patches, you always need to verify that the patch is installed correctly and is working properly.

Automated patch management tools are infamous for updating the registry keys to reflect full installation, yet failing to recognize that the patch download was disrupted-thus, incorrectly showing that the patch was successfully deployed. Then there are the patches that just don't work or undo the fixes installed by previous patches. If these issues aren't corrected, they will create problems that will slow future patching and performance.

This is especially important if the security department isn't the one doing the patching. Network and business unit managers will swear up and down that they deployed a patch, but verification is up to you.

You'll need to pull out those same discovery, vulnerability assessment and penetration testing tools we talked about earlier. When used in concert, these tools will verify the effectiveness of your patch rollout, identify which systems need further work and measure the level of residual exposure.

By taking the time to verify patches, you're essentially saving time during next rollout cycle. You won't be troubled by the mistakes of previous deployments and will be able to focus on the work in front of you.

About Time

Each system that you fail to remediate in a given cycle is a threat to your enterprise. It may be a home PC connecting through a VPN, or a developer's server attached to a production environment. The point of the patch management process is to get as close to 100 percent as possible.

What is the standard for patching? What percentage of systems should be patched within a week of a patch's release? What percentage of unpatched machines is an acceptable risk?

There are no right answers. Enterprises must develop their own metrics for measuring the success of their patch management programs. In the end, by employing these methods for continual improvement, your patch management system will reduce the vulnerability exposure and remediation time associated with enterprise-wide patch deployment.

Originally published in Information Security Magazine

A five-point strategy for secure remote access.

Managing secure remote access is a tough job. Because remote systems may directly connect to the Internet rather than through the corporate firewall, they pose an increased risk to your network environment. Virus and spyware protection, and a general VPN network policy isn't enough to keep these systems – and the network they connect to -- safe. Here are five best practices for providing secure remote access.

1. Software controls policy

Create a policy that defines the exact security software controls that must exist on systems with remote access. For example, you may need to spell out that antivirus, anti-spyware and desktop firewalls must be installed and configured in a specific manner with the latest signatures, along with which vendors are acceptable. The best practice is to distribute the policy along with the connection setup or similar instructions for end users. Often a zero-tolerance policy is best for endpoint security. End users should meet a set of guidelines before connecting to the network. No AV, antispyware and desktop firewall? No remote access allowed. The policy should also spell out what ports and services may be exposed on the system.

2. Endpoint security management

Choose a vendor that offers comprehensive endpoint security management and policy enforcement as part of their VPN or remote access solution. It is best to mandate that all remote users use the enterprise sponsored VPN client. That's the only way you are going to get true policy compliance and assurance of endpoint security posture. Your chosen remote access solution should be able to refuse connections for endpoint systems that do not meet the policy compliance checks. Ideally, the solution should tell end users which items are out of compliance so they can remediate the situation prior to attempting to reconnect. This cuts down on help desk calls.

3. Enforce corporate policy compliance

Inform end users that corporate security policy extends to their remote desktop when connected to the enterprise network. For example, no file sharing and other disallowed use while connected to the corporate network.

4. Reporting features

Reporting on end user compliance is critical. Most of the solutions mentioned above offer reporting capabilities to keep admins updated on the status of the connecting endpoints. Depending on the number of users you have to manage, it may be wise to set up alarms that e-mail admins when a machine that is significantly out of compliance tries to connect. In some cases administrative intervention may be warranted -- especially when other access methods to the network may exist.

5. Periodically review policy and reports

Every couple of months, review policies and reports to identify trends and patterns in access violations. This is important to ensure that the policy and technical controls are addressing your remote access security needs. If you find trends in access violations, add or modify policies accordingly.

Originally posted on TechTarget SearchSecurity.com

Surviving a Security Audit

We've all seen them before, those blue suits carrying shiny leather briefcases: Auditors. They march into our shops, asking question after question, touching and probing everything connected to a CAT 5. They check for everything from industry best practices to security standards to government regulations. The result is usually a thick report that grades your security program as pass or fail. The CISSP exam is nothing compared to this pressure.

But, auditors -- whether they're internal or third parties -- are a security professional's friends. They are a second set of eyes, looking at your policies, infrastructure and practices and verifying the areas in which you're doing well, and those that need work. Most importantly, they tell you how well you're complying with standards and regulations, such as ISO 17799 and Sarbanes-Oxley.

Audits may be stressful, but they don't have to be. A few simple steps will help you handle auditors, avoid common mistakes and reduce -- if not eliminate -- the stress.

Whether you're dealing with internal reviews or external specialists, the key to surviving a security audit is starting on the right foot.

Begin by scheduling a meeting with management to select a security audit response team -- a person or group that has the authority to facilitate the auditors' needs and respond to their inquiries.

The size of your enterprise and the scope of the audit will determine the size of your response team. For departmental and program audits, a point person may suffice. For broader internal and most third-party audits, you'll want a security audit response team composed of representatives from key departments, management and internal auditors.

Having the right people on your audit response team is critical. People who either have the answers on hand or can quickly investigate issues and report back to the auditors can help move an audit along faster.

Next, schedule a short meeting with the auditors. This will familiarize your organization with the audit process and set a good foundation. It will also help you determine the time commitments and resources you'll need to support the auditors.

During the meeting, you'll want to ask:

Which type of audit is being conducted?
Which methodology will the auditors follow? Will they measure you against your company's security policies, industry standards (ISO 17799), laws (HIPAA, GLBA, Sarbanes-Oxley) or a combination?
What is the scope of the audit, and which systems will be examined?
What documentation and materials will the auditors need?
What dates do the auditors plan to be on site? How long will it take to complete the audit?
What support and special considerations do the auditors require (e.g., private offices and workspace, telephones and faxes, network access)?
With this basic information in hand, it's time to collect the materials you'll need for the audit.
Documentation is king

Documentation is the key to explaining how your security program works. The auditors will use this documentation as a guide for reviewing and measuring your security program.

Common audit documents describe the system, security policies, operational procedures, network and system diagrams, process charts, change control procedures, process definitions, security scans/reports, test results and, of course, logs. If your organization has been audited in the past, you probably already have most of the information and materials you need. But, they will likely need updating, since no two audits are exactly alike -- especially if you're switching auditors.

It's the audit response team's job to sift through this mountain of paperwork and check each document for relevance. You want to be thorough, but don't over-document.

The end product should be logically organized and placed in a binder for the auditors. The easier you make it for them to find information, the smoother the audit will go.

Set the tone

Prepare a formal presentation to introduce the auditors to the process or system they will be reviewing. Every environment is unique, and an overview will make their jobs -- and yours -- easier.

Include slides of all systems, networks and applications being audited. Be specific. Don't just tell them your front-end Web server is Apache 2, but also that it proxies traffic to a J2EE application server, and that both servers run on Red Hat Linux.

Explain your applications and processes and how they relate to the business. Don't just say what's in your infrastructure. Sometimes systems, architectures and configurations don't make sense to outside observers until they're put into context.

Cover the major areas of security. Include identification, authentication, authorization, confidentiality, nonrepudiation, integrity, cryptography, audit and availability for each system. Explain how your security program addresses these needs and what the controls are for each.

Don't try to hide the ugliness in your infrastructure. Auditors will find it anyway. Highlight the areas that need improvement, as well as your strengths. Candor will reduce the likelihood that your presentation will be viewed as a smokescreen.

Supporting documents should back up everything noted in your presentation and be included in the documentation binder.

The auditors will have plenty of questions. The key to surviving their interrogation is to provide answers that reference the presentation or documentation. For example, if they ask about controls that separate account requests from approval and setup, your answer should be something like, "As mentioned in the presentation and supported by the account control document on page 27 of the binder, our process requires that an approval be granted by product operations prior to the MIS group setting up an account." This type of response shows that you know your own policies and processes.

Not knowing an answer isn't a sin. Don't answer questions with vague or misleading statements that can't be substantiated. It's OK to defer answering until you've had time to do research. Just say, "I don't have an answer now, but I'll investigate it and get back to you." Honest answers followed by strong evidence are always better than going out on a limb.

Support your auditors

Auditors should never be given root or administrative access to servers without a chaperone. However, depending on the type of audit and the auditors' methods, you may need to provide them with restricted access to systems and/or the data center. Supervising the auditors shows due care and will reflect well on your organization.

Auditors will inspect devices and software, but they will spend more time reviewing policies and interviewing employees and users. An administrative liaison is instrumental in helping auditors find documents that weren't included in the binder, as well as setting up interviews and meetings with key staff members.

Escorting and supervising your auditors gives you the opportunity to see the things they look at and hear the questions they ask your users. You can engage them in conversations about trends and standards, and answer any questions as they move through the system. Auditors appreciate this level of cooperation.

Receiving the report

Insist on a wrap-up meeting at the end of the auditors' site visit. Request a draft copy of any reports that will be issued and review them for accuracy (read: "sneak peek at what's coming"). Most auditors are willing to provide a draft and maybe even a short conference call to go over the findings. Once you receive the draft report, ask if you "passed."

In addition to their observations during their site visit and the documentation you have provided, they may follow up with a few more questions or request additional information. Responding quickly shows professionalism and saves money, since delays often end up as billable hours. Some audit reports will have a management response section in which you can rebut or respond to findings. Use this opportunity to describe what your group is doing to correct security deficiencies. Exercise caution, though, since a response will also give the auditors something to look for when they return for the follow-up.

Fixing the problems

Immediately following the audit, develop a remediation plan to address any deficiencies or recommendations made by the auditors. Major audits are usually performed annually, while focused audits happen more frequently. The initial audit -- even if you change auditing firms -- serves as a performance benchmark from which auditors will measure improvement or slippage since their last visit.

For every finding that requires remediation, you should have a clear idea of what changes to the system or policy would be acceptable, the criticality of these changes and how much time you have to correct them. Even if you can't complete the remediation before the next audit, the steps you take now will show you're working toward improvements.

Finally, you need to control your managers' expectations following the report's release. Celebrate specific successes and systematically root out failures. Make sure they understand that having passing grades in one area doesn't mean you can forget about shortcomings in others. And, don't let them believe that throwing money at the problem will solve everything; focused remediation plans will bolster their confidence in you.

Originally published in Information Security Magazine

How to conduct a Business Impact Analysis

What is a business impact analysis, what are the benefits of a BIA and how to do you conduct one?

Conducting a business impact analysis is hard work and takes time. But once this data is collected, security practitioners can confidently request resources, and more importantly, prioritize security efforts across the enterprise.

Simply stated, BIA is an analytic process that aims to reveal business and operational impacts stemming from any number of incidents or events.

A BIA traditionally leads to a report detailing likely incidents and their related business impact in terms of time and dollars. For example, a BIA report for an online retailer may include a Web site outage of one day with the loss calculated as the yearly gross sales divided by number of days per year the site is open for business.

In order to conduct a BIA you need to understand the business operations of your company in detail. You need to roll up your sleeves and reach out to operational folks to get the real picture. I remember one such exercise on a consulting engagement at a large bank where it was assumed that if the tellers lost their computer terminals that the dollar impact per hour was in the millions. The bank tellers later told me that when the terminals aren't available they can continue accepting deposits and other transactions, then manually batch the transactions at the end of the day. There was actually a five- to seven-hour window of no real loss of revenue.

Here is a simple step-by-step approach that will put you on your way to conducting a successful BIA.

1. Document the gross revenue and net profit your organization generates per year. This data sets the upper bound for business losses related to business operations. It will not, however, set the limits for reputation, regulatory or legal losses that can rise above yearly revenue.

2. Define the critical business systems your organization operates. This data can be entered and tracked in a spreadsheet. In many cases the revenue data can be linked to critical systems. This is especially true in e-commerce-driven companies.

3. Classify each system as business critical, important or non-critical. Ask system operators what would happen if a particular system was not available for an hour, a day or a week. In most cases you can quickly classify systems based on operator responses.

4. Document which systems have cross dependencies. There may be non-critical systems that act as upstream or downstream components to critical systems. For example, DNS service may not appear to be critical to an online store until it is discovered that the credit card gateway relies on DNS to send credit card requests and process transactions. This type of cross dependency may require a reclassification of systems when linked to critical applications.

5. Estimate the financial, revenue and non-revenue impacts associated with each system. For example, a payment gateway server for fax orders that does only 1% of the total revenue of the company can easily be estimated as .01 x gross revenue. If data does not exist or is not easy to estimate, the replacement cost (including labor) can be used for important and non-critical systems. For non-revenue related systems, note impact. For example, if the payroll system is not working, employees may not get paid on time -- which may cause other issues.

6. Estimate the cost to identify, remediate, recover and resume operations for each system in the spreadsheet. Include labor, hardware and software costs. For incidents that result in negative reputation, legal and regulatory outcomes, include estimate of fines, legal costs or a marketing campaign to win back customer confidence. Add these costs to impacts defined in step five.

7. Identify the Maximum Acceptable Outage (MAO) for each system. This is the time from the detection of the outage to obviation of importance to business. For example, if an online bookseller's Web site is down for over a week, it may lose all customers to the competition. However, an overnight outage may only result in a few lost orders. Some real-time financial industry systems may have very low MAO values, where more elongated global supply-chain processes with built-in delays may have MAO values that exceed a month.

8. Identify and document potential system threats, severity and the probability at which they may occur. For example, a datacenter fire severity would be 1.00 (on a .0–1.0 scale) but the probability may only be .01 (1%) in a given year. Threat statistics are available from a variety of sources and are used by insurance companies to calculate insurance premiums. Create a threat score for each incident type in a different section of the same spreadsheet. In the above example you would multiply (.01 x 1.0 =.01) and yield a combined risk score of .01 or 1%. Do this for all conceivable threats. You will also want to list one generic loss at 100% just to have a line item that reflects a complete loss for each system regardless of the incident or probability. This sets the upper bound for the system valuation.

9. Now you have most of the data needed to start the process. It is best to use the simple formula functions that a spreadsheet provides. For every system you have defined with a loss value, multiply the series of values from the threats listed in step eight with the combined loss values from step six to see the relative loss or impact per system. Do this on a line item basis. For each system calculate all possible listed threats. Do not include items that are not physically possible. For example, if you have business systems in Malaysia and New York, don't include the volcano or similar incidents that can't really happen in New York.

10. In this last step you will sort the data you have to show the top priority systems both from a business criticality and impact perspective. In the spreadsheet, select all columns in the sheet and use the "auto-filter" function on the data-sorting menu of your spreadsheet to link all the columns relationally. You can now sort on any of the variables in the sheet. Optionally, you can create a scorecard-like report by dressing up the spreadsheet, or add a narrative document and use the spreadsheet as the supporting data source.

Your BIA report can be used to request and prioritize resources, and incident-response activity. If done properly, it will be in a format your CFO and finance department can understand and include impact data gathered from these very same people, thus overcoming any objections or pushback on the validity of your report and subsequent resource requests!

Originally published on TechTarget SearchSecurity.com

Email Security and Compliance Best Practices for the Financial Services Industry

Managing email regulatory compliance and security in the financial services sector can be a daunting task. Email can be both the best and worst thing for the business. On the one hand it speeds up the business and makes servicing customers and partners a breeze, but there is a dark side. One high-profile case which involved a star investment banker at Credit Suisse First Boston, who sent e-mail to over 400 subordinates telling them to clean up their e-mail accounts. Federal prosecutors used that e-mail as evidence in a cover-up of improper trading at CSFB. The banker was later convicted on the obstruction of justice charges.

This blog post will help you understand the issues present and offer best practices to help manage compliance all while getting the benefits of this crucial communications tool.

The First Step is a Well Crafted Policy

Before you can bring control to email you must first define a policy. It may seem very basic, but your e-mail security policy must define what e-mail is exactly.

A good working definition would cover all electronically transmitted messages, regardless of format (HTML, XML, RTF, etc), attachments (documents, spreadsheets, graphics, etc.) and supporting infrastructure (the servers that transmit and store e-mail). For financial services this list will include such services as Bloomberg mail and instant messaging, Internet mail providers and of course your in house MS Exchange, Lotus Notes, or other email system.

You will need to refer to your information security policy or data protection policy (if available) to have a crisp definition of your company’s specific data classification framework. This is important if you decide that certain information must not be transmitted insecurely or at all via email. We will discuss this more in detail in the data leakage section below.

Now that you have defined what email is its time to consider the myriad of regulations that apply to it. For most in the financial services industry a good starting point is the SEC, for self regulated organizations, check with your governing body regarding regulations applicable to email.

Archiving Email

We will focus on the main regulatory issues in this TIP. For starters the requirement to archive email for specified period, usually 10 years should be at the top of your list. Archiving must be done in a manner that prevents users from deleting what could be important emails later in an investigation. The best way to accomplish this goal is to have both incoming and outgoing email written in real-time to an archive. This prevents users from mass deleting emails. It’s best to consider a secure offsite archive. Ideally this archive is managed by administrators without a conflict of interest, such as an outsourced provider, thereby lessening the chance of malicious insider email and data destruction.

Your choice of archive technology and/or outsourced provider should include protections against altering or deletion. A forensically compliant system is the best. Here there are cryptographic checksums, hashes, encryption, signatures, timestamps and other data protection mechanisms that can stand up in an investigation or against cross examination in a court of law. When something was emailed may be as important as what was actually emailed. Think back to the Martha Stewart case, the timing of communications can be critical. That’s why nothing less than a rock solid forensically compliant system is best.

Supervision Review Capability

Now that you are capturing the emails, securely archiving the messages and attachments you can focus on the next general set of must do items from a regulatory perspective. Supervisory review of email sent through the system is critical to meeting compliance objectives. You must have a program and policy in place that ensures regular review of the email content that is flowing though your company. The review has to be done in such a manner that it constitutes due care and monitoring to catch illicit or prohibited communications. The workflow for this may have to meet other requirements such as keyword matching, randomness, frequency or target specific roles within the organization such as the trading desk. Your solution of choice must support these policy or regulatory requirements.

Detailed Reporting is a Must

In order to prove the effectiveness of your regulatory compliance program, you need to produce detailed reports on email activity. When the auditors come they will expect to see reports. For starters your reporting should include the following.

• Measures of the effectiveness of the supervisory process.
• The number non-compliant messages and policy violations in defined time periods.
• Actual messages reviewed and analyzed by supervisors.
• Tracking of outcomes or actions on violations detected.
• Volume of email archived by groups or users.
• System capacity remaining for archive.
• Access violations or archive tampering attempts.
• Audit reports of access to the archive and messages.

Don’t underestimate the importance of reporting. If you miss these critical capabilities you may find yourself with a failed audit despite your otherwise solid archiving practices.

Searching and Discovery Support

At this stage you have a good understanding of what it takes to document, capture, review and report on your email compliance program. This is all good, until you get hit with your first discovery request, which can turn your world upside down. A simple email discovery request can cost hundreds of thousands of dollars in labor, lost productivity, hardware and software when all is said and done.

It is therefore very important that your implementation support robust and secure search capabilities. A discovery request will often include specific users, keywords, phrases or time periods (sometimes all of these at once). So just why is a precise and robust search capability required? Well sometimes searches can produce unwanted artifacts that are not material to the investigation at topic but are “none the less” serious. For example inappropriate activity recorded in email is often discovered and the release of this information to outsiders could have consequences.

Your email archiving solution should offer laser precise search capability and be able to target searches to a limited set of email messages. To quote on old far eastern saying, “you may go looking for worms and find a snake”.

Data Leakage

All the archiving in the world is not going to stop sensitive data from leaking out of the enterprise. There are two basic concerns here, the first is the data in the archive. It should be encrypted with a know, trusted and recognized encryption algorithm such as AES. The external provider should not be able to access your data in the archive. Also in the event of a system breach, the email won’t be disclosed if its protected by strong encryption.

The second concern is of course sensitive data leaking in emails being sent outside the firewall. To deal with this risk you need to define the types of data that fit this classification.

E-mail gives rogue or hapless users an easy way to expose financial statements and other sensitive material. Your email policy should indicate which material shouldn't be sent electronically. This won't stop corporate espionage, but it will help keep honest users from inadvertently leaking financial data to their entire global address list.

As we mentioned earlier in the policy section, your data protection policy or data classification framework plays an important role in policy enforcement. Many of the email data leakage solutions available require a concept of classification.

The first layer of defense in secure email proxy solutions is often keyword or expression matching to prevent data leakage. For example sensitive data such as social security numbers may take the form 000-00-0000 through 999-99-9999, a proxy would detect this pattern and block the message, perhaps triggering an event or alarm for the security administrator to review. Similarly keyword systems may catch words like sell short, hot stock and the like and block these types of messages. These approaches can be hit or miss and won’t catch everything.

A second layer of defense is often required. Tagging data, documents or messages with classification levels can prevent sensitive, restricted information from leaving the company mail system. Many appliance based solutions offer a combination of technologies to prevent deliberate or accidental data leakage from emails send beyond the firewall.

If you must send sensitive data outside the firewall, a policy requiring users to protect intellectual property and proprietary information is meaningless without giving them the proper security mechanism. For e-mail, security usually means encryption.
An e-mail security policy should include the types of accepted encryption, when it should be used and how it will be implemented. For instance, installing PGP on executive client machines should protect routine documents, while network-based encryption tools are likely more appropriate for users who exchange sensitive information.
Protecting electronic information exchanges is essential for financial services firms.

Use Disclaimers as Damage Control

Enterprises should consider adding a disclaimer statement to the end of each e-mail, informing recipients of the sending organization's policy, the nature of the e-mail (such as "For Official Use Only") and what material it disavows. For instance, a securities trading firm may include in its disclaimer that it accepts no responsibility for falsely or improperly sent messages, and that any violation should be reported to a security manager.
A disclaimer puts the onus on recipients to act responsibly when receiving improperly disclosed information. One such disclaimer reads: "This message is intended only for the use of the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error, please destroy all copies of this message and its attachments and notify us immediately." Disclaimers offer no guarantee of compliance, but they do establish a legal standing for making claims against those who perpetuate a security violation.

Governance is Key

E-mail security policies should outline the roles and responsibilities of those managing the e-mail system. They set expectations as to how security managers, e-mail admins and other department managers respond to e-mail issues and security.
An e-mail security policy is worthless unless users are presented and periodically reminded of it. Best practice is to give new employees a copy of the policy when they are hired. Enterprises should treat e-mail security policies as dynamic documents that evolve to meet changing legal and operating conditions, technologies and threats. Annual reviews and revisions will ensure the policy keeps up with changing needs.

The Final Word

The financial services sector has perhaps on of the most difficult email security challenges of any industry. This article has armed you with proven best practices that can help mitigate your regulatory e-mail risks through sound policy, secure archiving, supervisory review practices, audit reporting and data leakage prevention.

Originally published on TechTarget SearchSecurity.com

This blog post will help you understand the issues present and offer best practices to help manage compliance all while getting the benefits of this crucial communications tool.

The First Step is a Well Crafted Policy

Before you can bring control to email you must first define a policy. It may seem very basic, but your e-mail security policy must define what e-mail is exactly.

A good working definition would cover all electronically transmitted messages, regardless of format (HTML, XML, RTF, etc), attachments (documents, spreadsheets, graphics, etc.) and supporting infrastructure (the servers that transmit and store e-mail). For financial services this list will include such services as Bloomberg mail and instant messaging, Internet mail providers and of course your in house MS Exchange, Lotus Notes, or other email system.

You will need to refer to your information security policy or data protection policy (if available) to have a crisp definition of your company’s specific data classification framework. This is important if you decide that certain information must not be transmitted insecurely or at all via email. We will discuss this more in detail in the data leakage section below.

Now that you have defined what email is its time to consider the myriad of regulations that apply to it. For most in the financial services industry a good starting point is the SEC, for self regulated organizations, check with your governing body regarding regulations applicable to email.

Archiving Email

We will focus on the main regulatory issues in this TIP. For starters the requirement to archive email for specified period, usually 10 years should be at the top of your list. Archiving must be done in a manner that prevents users from deleting what could be important emails later in an investigation. The best way to accomplish this goal is to have both incoming and outgoing email written in real-time to an archive. This prevents users from mass deleting emails. It’s best to consider a secure offsite archive. Ideally this archive is managed by administrators without a conflict of interest, such as an outsourced provider, thereby lessening the chance of malicious insider email and data destruction.

Your choice of archive technology and/or outsourced provider should include protections against altering or deletion. A forensically compliant system is the best. Here there are cryptographic checksums, hashes, encryption, signatures, timestamps and other data protection mechanisms that can stand up in an investigation or against cross examination in a court of law. When something was emailed may be as important as what was actually emailed. Think back to the Martha Stewart case, the timing of communications can be critical. That’s why nothing less than a rock solid forensically compliant system is best.

Supervision Review Capability

Now that you are capturing the emails, securely archiving the messages and attachments you can focus on the next general set of must do items from a regulatory perspective. Supervisory review of email sent through the system is critical to meeting compliance objectives. You must have a program and policy in place that ensures regular review of the email content that is flowing though your company. The review has to be done in such a manner that it constitutes due care and monitoring to catch illicit or prohibited communications. The workflow for this may have to meet other requirements such as keyword matching, randomness, frequency or target specific roles within the organization such as the trading desk. Your solution of choice must support these policy or regulatory requirements.

Detailed Reporting is a Must

In order to prove the effectiveness of your regulatory compliance program, you need to produce detailed reports on email activity. When the auditors come they will expect to see reports. For starters your reporting should include the following.

• Measures of the effectiveness of the supervisory process.
• The number non-compliant messages and policy violations in defined time periods.
• Actual messages reviewed and analyzed by supervisors.
• Tracking of outcomes or actions on violations detected.
• Volume of email archived by groups or users.
• System capacity remaining for archive.
• Access violations or archive tampering attempts.
• Audit reports of access to the archive and messages.

Don’t underestimate the importance of reporting. If you miss these critical capabilities you may find yourself with a failed audit despite your otherwise solid archiving practices.

Searching and Discovery Support

At this stage you have a good understanding of what it takes to document, capture, review and report on your email compliance program. This is all good, until you get hit with your first discovery request, which can turn your world upside down. A simple email discovery request can cost hundreds of thousands of dollars in labor, lost productivity, hardware and software when all is said and done.

It is therefore very important that your implementation support robust and secure search capabilities. A discovery request will often include specific users, keywords, phrases or time periods (sometimes all of these at once). So just why is a precise and robust search capability required? Well sometimes searches can produce unwanted artifacts that are not material to the investigation at topic but are “none the less” serious. For example inappropriate activity recorded in email is often discovered and the release of this information to outsiders could have consequences.

Your email archiving solution should offer laser precise search capability and be able to target searches to a limited set of email messages. To quote on old far eastern saying, “you may go looking for worms and find a snake”.

Data Leakage

All the archiving in the world is not going to stop sensitive data from leaking out of the enterprise. There are two basic concerns here, the first is the data in the archive. It should be encrypted with a know, trusted and recognized encryption algorithm such as AES. The external provider should not be able to access your data in the archive. Also in the event of a system breach, the email won’t be disclosed if its protected by strong encryption.

The second concern is of course sensitive data leaking in emails being sent outside the firewall. To deal with this risk you need to define the types of data that fit this classification.

E-mail gives rogue or hapless users an easy way to expose financial statements and other sensitive material. Your email policy should indicate which material shouldn't be sent electronically. This won't stop corporate espionage, but it will help keep honest users from inadvertently leaking financial data to their entire global address list.

As we mentioned earlier in the policy section, your data protection policy or data classification framework plays an important role in policy enforcement. Many of the email data leakage solutions available require a concept of classification.

The first layer of defense in secure email proxy solutions is often keyword or expression matching to prevent data leakage. For example sensitive data such as social security numbers may take the form 000-00-0000 through 999-99-9999, a proxy would detect this pattern and block the message, perhaps triggering an event or alarm for the security administrator to review. Similarly keyword systems may catch words like sell short, hot stock and the like and block these types of messages. These approaches can be hit or miss and won’t catch everything.

A second layer of defense is often required. Tagging data, documents or messages with classification levels can prevent sensitive, restricted information from leaving the company mail system. Many appliance based solutions offer a combination of technologies to prevent deliberate or accidental data leakage from emails send beyond the firewall.

If you must send sensitive data outside the firewall, a policy requiring users to protect intellectual property and proprietary information is meaningless without giving them the proper security mechanism. For e-mail, security usually means encryption.
An e-mail security policy should include the types of accepted encryption, when it should be used and how it will be implemented. For instance, installing PGP on executive client machines should protect routine documents, while network-based encryption tools are likely more appropriate for users who exchange sensitive information.
Protecting electronic information exchanges is essential for financial services firms.

Use Disclaimers as Damage Control

Enterprises should consider adding a disclaimer statement to the end of each e-mail, informing recipients of the sending organization's policy, the nature of the e-mail (such as "For Official Use Only") and what material it disavows. For instance, a securities trading firm may include in its disclaimer that it accepts no responsibility for falsely or improperly sent messages, and that any violation should be reported to a security manager.
A disclaimer puts the onus on recipients to act responsibly when receiving improperly disclosed information. One such disclaimer reads: "This message is intended only for the use of the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error, please destroy all copies of this message and its attachments and notify us immediately." Disclaimers offer no guarantee of compliance, but they do establish a legal standing for making claims against those who perpetuate a security violation.

Governance is Key

E-mail security policies should outline the roles and responsibilities of those managing the e-mail system. They set expectations as to how security managers, e-mail admins and other department managers respond to e-mail issues and security.
An e-mail security policy is worthless unless users are presented and periodically reminded of it. Best practice is to give new employees a copy of the policy when they are hired. Enterprises should treat e-mail security policies as dynamic documents that evolve to meet changing legal and operating conditions, technologies and threats. Annual reviews and revisions will ensure the policy keeps up with changing needs.

The Final Word

The financial services sector has perhaps on of the most difficult email security challenges of any industry. This article has armed you with proven best practices that can help mitigate your regulatory e-mail risks through sound policy, secure archiving, supervisory review practices, audit reporting and data leakage prevention.

Originally published on TechTarget SearchSecurity.com