Tag Archives: DLP

DRM versus DLP

A common question for a large company that needs to protect intellectual property from theft and abuse is choosing the right balance of technology, process and procedure. It has  been said that the Americans are very rules-based in their approach to security and compliance where the the Europeans are more principles-based.

This article presents a systematic method for selecting and cost-justifying data security technology to protect  intellectual property theft and abuse.

The original presentation was given at the October 2, 2009 DLP-Expert Russia meeting in Istra (just outside of Moscow)

Click here to download the presentation

Tell your friends and colleagues about us. Thanks!
Share this

SOX IT Compliance

A customer case study – SOX IT Compliance

We performed a Sarbanes-Oxley IT top down security assessment for a NASDAQ-traded advanced technology company. The objectives for the study were to evaluate the internal and external threats that impact the company’s information assets. Using the Business threat modeling (BTM) methodology, a practical threat analysis PTA threat model was constructed and a number of threat scenarios were analyzed. Data was collected using structured interviews and network surveillance (with a Fidelis XPS appliance). Assets were valuated by the CFO and the IT security operations and technologies were valuated by the CIO. The output of the study was a cost-effective, prioritized program of security controls.This program was presented and approved by the management board of the company- leading to an immediate cost savings of over $120,000/year in the information security budget.

The detailed threat model was provided to the client and is currently used to perform what-if analysis and track the data security implementation. 

Download the data security case study and download the data security report to the management.

Conclusions

  1. The bulk of the security budget is currently spent on sustaining network perimeter security and system availability. Not surprisingly, these countermeasures are not particularly effective in mitigating insider threats such as lost or stolen hardware and information leakage, which now dominate the company’s risk profile.

  2. In corporate IT Security operations: The two major data security systems that were purchased in 2007, Imperva and Fidelis XPS Extrusion Prevention System have not yet been fully implemented and do not provide the expected benefit. To be specific, Imperva needs to be able to produce real-time alerts on violations based on logical combinations of OS user, DB application and DB user. Fidelis needs to be deployed in the subsidiaries. Monitoring from both systems needs to become a daily operational tool for the security officer.

  3. In the Asia Pacific region: Loss of notebooks to the tune of 2-3 / quarter is a major vulnerability although content abuse of the corporate network is assessed as negligible due to cultural factors.

  4. In general: Publicly facing FTP servers must be monitored carefully for violations of the company acceptable usage policy. In the course of the risk assessment, we discovered strategic plans and proprietary source codes that were stored on publicly accessible FTP servers.

Tell your friends and colleagues about us. Thanks!
Share this

DLP in on-line trading

A customer case study  – DLP helped diamonds.com be more secure and more competitive.

We designed and implemented a large scale IT infrastructure modernization project that was tasked with improving availability, scalability and security of the online diamond trading networks at diamonds.com and diamonds.net. Network DLP appliances were deployed in the US and in EMEA at the company’s hosted server farms in order to help protect sensitive customer and commercial data.

Read the Customer solution case study

Tell your friends and colleagues about us. Thanks!
Share this

Using DLP to prevent credit card breaches

I think that Data Loss Prevention is great way to detect and prevent payment card and PII data breaches.

Certainly, all the DLP vendors think so.  Only problem is, the PCI DSS Council doesn’t even have DLP in their standard which pretty much guarantees zero regulatory tail wind for DLP sales to payment card industry players.

I’m actually impressed that Symantec didn’t manage to influence the PCI DSS council to include DLP in the standard. An impressive display of professional integrity and technology blindness.

A while back, we did a software security assessment for a player in the online transaction space.

When I asked the client and auditor what kind of real time data loss monitoring they have in place, just in case, they have a bug in their application and/or one of their business partners or trusted insiders steals data, the answers where like “umm, sounds like a good idea but it is not required by PCI DSS 2.0”

And indeed the client is correct.

PCI DSS 2.0 does not require outbound, real time or any other kind of data loss monitoring.

The phrases “real time” and “data loss” don’t appear in the standard. The authors of the standard like file-integrity monitoring but in an informal conversation with a PCI DSS official in the region, he confessed to not being familiar with DLP.

Here are a few PCI  monitoring requirements.

None of these controls directly protect the the payment card from being breached. They are all indirect controls and very focused on external attackers – not on trusted insiders nor business partners.

  1. Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).
  2. If automated monitoring of wireless networks is utilized (for example, wireless IDS/IPS, NAC, etc.), verify the configuration will generate alerts to personnel.
  3. Deploy file-integrity monitoring tools to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.
  4. Monitor and analyze security alerts and information, and distribute to appropriate personnel.
  5. Verify through observation and review of policies, that designated personnel are available for 24/7 incident response and monitoring coverage for any evidence of unauthorized activity, detection of unauthorized wireless access points, critical IDS alerts, and/or reports of unauthorized critical system or content file changes.

Oh man.

Tell your friends and colleagues about us. Thanks!
Share this

The ethical aspects of data security

Ethical breaches or data breaches.

I was standing in line at Ben Gurion airport, waiting for my bag to be x-rayed. A conversation started with a woman standing next to me in line. The usual sort – “Where are you traveling and what kind of work do you do?”. I replied that I was traveling to Warsaw and that I specialize in data security and compliance – helping companies prevent trusted insider theft and abuse of sensitive data.

She said, “well sure, I understand exactly what you mean – you help enforce ethical behavior of people in the organization”.

I stopped for a moment and asked her, hold on – “what kind of business are you in”? She said – “well, I worked in the GSS for years training teams tasked with protecting high echelon politicians and diplomats. I understand totally the notion of enforcing ethical behavior”. And now? I asked. Now, she said, ” I do the same thing, but on my own”.

Let’s call my new friend “Sarah”.

Sarah’s ethical approach was for me, a breath of fresh air. Until that point, I had defined our data security practice as an exercise in data collection, risk analysis and implementation of the appropriate technical security countermeasures to reduce the risk of data breach and abuse. Employees, competitors and malicious attackers are all potential attackers.  The objective is to implement a cost-effective portfolio of data security countermeasures – policies and procedures, software security assessments, network surveillance, data loss prevention (DLP) and encryption at various levels in the network and applications.

I define security as protecting information assets.

Sarah defines security as protecting ethical behavior.

In my approach to data security, employee behavior is an independent variable, something that might be observed but certainly, not something that can be controlled. Since employees, contractors and business partners tend to have their own weaknesses and problems that are not reported on the balanced score card of the company, my strategy for data security posits that it is more effective to monitor data than to monitor employees and prevent unauthorized transfer or modification of data instead of trying to prevent irrational or criminal behavior of people who work in the extended enterprise.

In Sarah’s approach to data security, if you make a set of rules and train and enforce ethical behavior with good management, sensing and a dosage of fear in the workplace; you have cracked the data security problem.

So – who is right here?

Well – we’re both right, I suppose.

The answer is that without asset valuation and analysis of asset vulnerabilities, protecting a single asset class (human resources, data, systems or network) while ignoring others, may be a mistake.

Let’s examine two specific examples in order to test the truth of this statement.

Consider a call center with 500 customer service representatives. They use a centralized CRM application, they have telephones and email connectivity. Each customer service representative has a set of accounts that she handles. A key threat scenario is leaking customer account information to unauthorized people – private investigators, reporters, paparazzi etc… The key asset is customer data but the key vulnerability is the people that breach ethical behavior on the way to breaching customer data.

In the case of customer service representatives breaching customer privacy, Sarah’s strategy of protecting ethical behavior is the best security countermeasure.

Now, consider a medical device company with technology that performs imaging analysis and visualization. The company deploys MRI machines in rural areas and uses the Internet to provided remote expert diagnosis for doctors and patients who do not have access to big city hospitals. The key asset transmitted from the systems for remote diagnosis is PHI (protected health information), and the key vulnerabilities are in the network interfaces, the applications software and operating systems that the medical device company uses.

In  the case of remote data transfer and distributed/integrated systems, a combined strategy of software security, judicious network design and operating system selection (don’t use Microsoft Windows…) is the correct way to protect the data.

My conversation with Sarah at the airport gave me a lot of food for thought.

Data loss prevention (DLP technology) is great  and  ethical employee behavior is crucial but they need to work hand in glove.

Where there are people, there is a need to mandate, monitor and reinforce ethical behavior using  a clearly communicated corporate strategy with employees and contractors. In an environment where users require freedom and flexibility in using applications such as email and search, the ethical behavior for protecting company assets starts with company executives who show from personal example that IT infrastructure is to be used to further the company’s business and improving customer service and not for personal entertainment, gain or gratification.

It’s the simple things in life that count.

Tell your friends and colleagues about us. Thanks!
Share this

The Microsoft monoculture as a threat to national security

This is probably a topic for a much longer essay, but after two design reviews this week with medical device vendor clients on software security issues, I decided to put some thoughts in a blog post.

Almost 8 years ago, Dan Geer, Rebecca Bace,Peter Gutmann, Perry Metzger, Charles Pfleeger, John Quarterman and Bruce Schneier wrote a report titled: CyberInsecurity: The Cost of Monopoly How the Dominance of Microsoft’s Products Poses a Risk to Security.

The report from a stellar cast of information security experts and thought leaders shows that the complexity and dominance of Microsoft’s Windows operating system in US Federal agencies makes the US government prone to cyber attack – a national security threat.

This was in September 2003.

Now fast forward to a congressional hearing on May 25, 2011 by the Committee on Oversight and Government Reform on “Cybersecurity: Assessing the Immediate Threat to the United States Listen to the youtube video – you will note the concern on potential damage to citizens due to virus infecting government PCs breaching personal information.

So the US government is still running Microsoft Windows and is still vulnerable to data security breaches. It seems that the Microsoft lobbying machine has been “successful” over the past 8 years on the Beltway, if you call threats to national security a success.

One of the commonly used canards by Microsoft monoculture groupies is that all operating systems have vulnerabilities and Windows is no better nor worse than Linux or OS/X. If “you” patch properly everything will be hunky-dory. There are a number of reasons why this is fallacious,  to quote the report:

  • Microsoft is a near-monopoly controlling the overwhelming majority of systems. This means that the attack surface is big, on a US national  level.
  • Microsoft has a high level of user-level lock-in; there are strong disincentives to switching operating systems.
  • This inability of consumers to find alternatives to Microsoft products is exacerbated by tight integration between applications and operating systems, and that integration is a long-standing practice.
  • Microsoft’s operating systems are notable for their incredible complexity and complexity is the first enemy of security.
  • The near universal deployment of Microsoft operating systems is highly conducive to cascade failure; these cascades have already been shown to disable critical infrastructure.
  • After a threshold of complexity is exceeded, fixing one flaw will tend to create new flaws; Microsoft has crossed that threshold.
  • Even non-Microsoft systems can and do suffer when Microsoft systems are infected.
  • Security has become a strategic concern at Microsoft but security must not be permitted to become a tool of further monopolization.

As a  medical device security and compliance expert, I am deeply concerned about medical devices that use Windows. If Windows is a threat to national security because it’s used in Federal government offices, Windows is really a bad idea when used in medical devices in hospitals.

I’m concerned about the devices themselves (the FDA classifies Web applications as medical devices also if the indications are medical-related) and the information management systems: the customer support, data collection, analysis management applications that are ubiquitous to networked medical devices.

There are two reasons why the FDA should outlaw Windows in medical devices and their information management systems.

Reason number 1 to ban Windows from medical devices is complexity. We know that the first sin of the 7 deadly sins of software development is making the software complex.  Complexity is the enemy of security because with complex software, there are more design flaws, more software defects and more interfaces where vulnerabilities can arise.

Similar to the history of data security breaches of retail systems, the medical device software industry is (or may soon be) facing a steeply increasing curve of data security and patient safety events due to the Microsoft monoculture.  We are not in Kansas anymore – not credit cards being breached, but entire hospital networks infected by Microsoft Windows viruses and patient monitoring devices that stop working because they got blue screens of death.  Since 300 million credit cards have been breached, it is a reasonable assumption that your card and mine is out there. The damage to your credit card being breached is minimal.  But, if your child was on a patient monitor that went offline due to a Microsoft Windows virus and a critical condition was not detected in time; it’s the difference between life and death.

The complexity and vulnerabilities of Windows technologies are simply not appropriate in the medical device space when you look at the complexity and weight of the components, the SQL injection vulnerabilities provided courtesy of naive ASP.NET programmers and the ever present threat of Windows viruses and malware propagated  by USB sticks and technician notebooks.

The Microsoft monoculture breeds a generation of programmers that are scared of the command line, unable to comprehend what happens behind the GUI and lured by the visual beauty of the development tools.  When a programmer uses a component and doesn’t know it works (see Visual Studio ) and shleps around a shitload of piping in his project, then the energies go into implementing a cute GUI instead of thinking about code threats.

This is on a grander scale, a rerun of Microsoft Powerpoint, where you spend 80% of your time in the application’s GUI instead thinking about and then just stating your message.

Reason number 2 to ban Microsoft Windows from medical devices is more subtle and related to systems management.   The Microsoft monoculture has bred a particular kind of thinking and system management best practices based on Windows servers and Windows PCs running in the office.  This IT system management strategy assumes that PCs are just personal devices that someone has to patch and that they will eventually get infected and or breached and or get a BSOD.

Unlike an office, a hospital is a highly heterogeneous and hostile environment. The system management strategy for network medical devices must be different.

Medical device vendors need to assess their software security with the design objective being a device that runs forever and serves the mission of the doctors and patients.

Medical devices are real time embedded systems living on a hospital network. They should be fail safe, not vulnerable to viruses and should not have to rebooted every few days.

Yes – it’s a tall bill and a lot of people will have to learn how to write code in embedded Linux.

But, there is no alternative, if we want to prevent the medical device industry from suffering the ignominy of the credit card industry.

 

Tell your friends and colleagues about us. Thanks!
Share this

Defining the insider threat

One of the biggest problems facing organizations is lack of rigorous definitions for trusted insider threats, data loss and how to estimate potential damage from a data loss event. With a lack of rigorous definitions for data loss and trusted insider threats, it’s hard to benchmark with other companies and difficult to select a good set of data security countermeasures.

Referring to work done by Bishop – “Defining the trusted insider threat”

An insider can be defined with regard to two primitive actions:

  1. Violation of a security policy using legitimate access, and
  2. Violation of an access control policy by obtaining unauthorized access.

Bishop bases his definition on the notion  “...that a security policy is represented by the access control rules employed by an organization.”

It is enough to take a glancing view at the ISO 27001 information security management standard to realize that a security policy is much more than a set of access control rules.  Security policy includes people policies and procedures,good hiring practices,  acceptable usage policies backed up by top management committment to data governance,audit,  robust outbound data security monitoring (or what is often called “DLP Light”) and incident response.  Information security management is based on asset valuation, measuring performance with security metrics and implementing the right, cost-effective portfolio of security countermeasures.

A definition of trusted insider threats  that is based on access control is therefore necassarily limited.

I would offer a more general definition of a trusted insider threat:

Any attack launched from inside the network by an employee, contractor or visitor that damages or leaks valuable assets by exploiting means (multiple accounts) and opportunity (multiple channels).

Using this definition, we can see that trusted insider threats is a matter of asset value and threat surface – not just access control:

  • For example, employees in an organization that crunches numbers of weather statistics have nothing to gain by leaking crunched data – since the assets have no intrinsic value.
  • For example, employee tendency to click on Microsoft Office documents can turn them into a trusted insider threat regardless of the access controls the organization deploys – as RSA learned recently.

RSA was hacked in the beginning of March 2011 when an employee was spear phished and opened an infected spreadsheet. As soon as the spreadsheet was opened, an advanced persistent threat (APT) — a backdoor Trojan — called Poison Ivy was installed. The attackers then gained free access into RSA’s internal network, with the objective of disclosing data related to RSA’s two-factor authenticators.

RSA is a big company with a big threat surface, lots of assets to attack and lots of employees to exploit.

The attack is similar to APTs used in the China vs. Google attacks from last year. Uri Rivner, the head of new technologies at RSA is quick to point out that that other big companies are being attacked, too:

“The number of enterprises hit by APTs grows by the month; and the range of APT targets includes just about every industry.Unofficial tallies number dozens of mega corporations attacked […] These companies deploy any imaginable combination of state-of-the-art perimeter and end-point security controls, and use all imaginable combinations of security operations and security controls. Yet still the determined attackers find their way in.”

Mitigating the trusted insider threat requires first of all defining whether or not there IS a threat and if so – finding the right security countermeasures to mitigate the risk.  One wonders whether or not RSA eats their own dog food and had deployed a data loss prevention system.  Apparently not.

Tell your friends and colleagues about us. Thanks!
Share this

Why data security is like sex

We all think about sex – men (most of the time), women (some of time) and teenagers (all the time).

Sex – despite the huge volume of content in the digital and print media, is one of those phenomena that demonstrate an inverse relationship between substance and talk.    The more talk, chances are, the less substance actually going on. The less talk, the higher a probability that something serious is really going on between you and your partner.  When things are cooking for you and your wife/girl friend  you don’t have time to be writing about it on your blog. When things are rough,  you will probably be a bit shy about going into detail on Facebook.  But it’s a lot easier to talk about other people, who’s hot and who’s not.

Just like data security and global terror.  It’s a lot easier to talk about the Middle East and ignore what’s happening in your own backyard.   It’s like  “other peoples money” – something you can spend without worrying too much.

Using this metaphor, the data security industry is like sex.   Lots of talk and press releases about data breaches, plenty of marketing communications written by clueless communications majors just out of school working for Symantec and Mcafee and recycling of Gartner reports ad nauseum.  But – a lot less in the vulnerability and risk mitigation department and generally low levels of willingness to talk about security failures in an organization or what really works.

Since this is part of the human chemistry – I don’t imagine this will change in the near future but for sure we will have a lot of fun, just like great sex.

Tell your friends and colleagues about us. Thanks!
Share this

Securing Web services in the cloud

Almost every SaaS (software as a service) is based on REST or XML Web services.  In this post, I’d like to provide a brief introduction to some typical threats and security countermeasures to protect Web services;

Malicious Attack on the message

The beauty of  HTTP Web Services is that traffic flows through port 80 and port 443 and it uses a human-readable format (XML or JSON). This is also the key vulnerability.  A typical IT / system administration approach that relies on protecting Web service providers with a firewall/IPS setup is not very effective.  We will explain why.

Firewalls do a good job of port monitoring and recognizing brute force malicious attack but are not good at being able to view the content of messages in order to detect and prevent more sophisticated security compromises. While most firewalls can recognize SOAP as well-formed HTTP traffic they cannot inspect the actual content of the SOAP message or JSON data. Web Services interfaces are much more complex than Web site interfaces which exchange HTML pages and forms. Web service interfaces are like software API’s and expose database functionality. In addition, an attacker has more information available to them. The message is often self-describing and clearly shows the data elements.

A Web service provider is a juicy, self-describing target.

Replay Attack
Similar to Denial of Service, replay attacks involve copying valid messages and repeatedly sending them to a service. Similar techniques for detecting and handling Denial of Service can be applied towards replay attacks. In some ways, replay attacks are easier to detect with Web Services because payload information is more readily available. With the right tools, patterns can be detected more easily even if the same or similar payload is being sent across multiple mediums like HTTP, HTTPS, SMTP, etc.

Buffer Overflow
An attacker can send a parameter that is longer than the program can handle, causing the service to crash or for the system to execute undesired code supplied by the attacker. A typical method of attack is to send an overly long request, for instance, a password with many more characters than expected. Similar to buffer overflow attacks; hackers often send malformed content to produce a similar effect. Sending in strings such as quotes, open parentheses and wildcards can often confuse a Web Service interface.

Dictionary Attack
Dictionary attacks are common where a hacker may either manually or programmatically guess passwords to gain entry into the system. Administrators should ensure that passwords are difficult to guess and are changed often.

Intrusion Detection of attacks by malicious outsiders
Proactively securing all of the possible misuses of Web Services is almost impossible. Security policies and strict access control management should help reduce the occurrence of intrusion. An IPS will detect anomalous attack behavior and if monitored may help the security team mitigate the threat.

Extrusion detection of attacks by trusted insiders
Attackers are usually thought to be outside of the organization. However, most security breaches occur from within the organization. With Web Services, more functionality is available to a more people. Access to confidential information or embezzlement of funds is just some of the possible internal security breaches that can be performed by employees or former employees. Because employees are the most familiar with internal systems, detection can be made extremely difficult. Unintentional compromises are also possible. If an interface is unsecured, an employee may accidentally access information that they are not intended to view. Since Firewalls are insufficient for data breach, we would require use of a DLP –  Data loss  prevention system such as Fidelis XPS or WebSense DLP.

Threat containment
Once a security breach is detected, being able to shut down systems and reject traffic from specific sources are important for handling a compromise.  A DLP system provides real-time detection, forensics recording and  the ability to drop traffic from specific IP source addresses in order to properly mitigate the threat.

Tell your friends and colleagues about us. Thanks!
Share this

Bank of America and Wikileaks

First reported in the Huffington Post in November 2010, the Bank of America has set up a Wikileaks defense team after an announcement by Julian Assange that Wikileaks has information from a 5GB hard drive of a Bank of America executive.

In a burst of wikipanic, Bank of America has dived into full-on counterespionage mode…15 to 20 bank officials, along with consulting firm Booz Allen Hamilton, will be “scouring thousands of documents in the event that they become public, reviewing every case where a computer has gone missing and hunting for any sign that its systems might have been compromised.”

Interesting that they needed Booz and Hamilton.  I thought Bank of America was a Vontu DLP (now Symantec) customer.  It says something about the technology either not working, being discarded or simply not implemented properly because the Wikileaks announcement was made in October 2009. So it took BoA over a year to respond.  Good luck finding forensics over a year after the leak happened.

This is a good thing for information security consultants and solution providers, especially if it drives companies to invest in DLP. There are some good technologies out there and companies that implement DLP thoughtfully (even if for dubious reasons) will be profiting from the improved visibility into transactions on their network and better protection of IP and customer data.

Ethics of the bank executive aside, it is conceivable (albeit totally speculative), that the Obama administration is behind the Wikileaks disclosures on US banking. It is consistent with the Obama policy that required banks to accept TARP funds and stress testing in order to make the financial institutions more beholden to the Federal government. This is consistent with the State Department cables leak, which also appears (from my vantage point in the Middle East) to be deliberately disclosed to Wikileaks in order further the agenda against the Iranians without coming out and saying so specifically.

Tell your friends and colleagues about us. Thanks!
Share this