Many executives ask,  “What should we do about APTs?” Executives at large organizations with serious intellectual property (like source code) have a  high level of concern because they  know others will try to take it. Conversely,there’s a large group that thinks, “I’m a $10-million manufacturing company in Ohio. I don’t think Chinese or North Korean hackers are going to be knocking on my door anytime soon.”

And, they are right. For many companies, APTs by definition aren’t a primary concern. The base starting point we all need to know is very simply that APTs are a type of targeted attack. This is where we start to get into the ‘why you should care’ part; because while APTs may not be a concern for many companies, targeted attacks are on everyone’s radar.

Here’s a simple fact. APT techniques used in state-sponsored attacks seeking IP are also used by organized criminal gangs looking to score your cash. No, not everything is a classic APT, but the same technology used by China to hack Google is used by cybercriminals to steal your customer data.

It’s a bit like a bullet-proof vest. Foreign governments and state-sponsored agents spend huge resources coming up with ammunition that will pierce that vest. Once the ammo becomes familiar, others outside the government begin using this ammo for their own purposes..

The same thing happens with attack methodologies. Let’s look at a classic APT and how quickly the techniques employed by it got into the hands of others.

The Aurora attacks of 2009 were among the first widely publicized APTs. Companies including Google, Adobe and Rackspace were targeted by a state-sponsored APT in November and December of that year. On January 12, 2010, Google publicly announced the attack. Only two days later, the zero-day exploit was revealed publicly and then nine days passed until Microsoft patched the primary vulnerability. At that time, the exploit was only detected by 26 percent of AV vendors, but within a single month more than 200 other websites were found to have been attacked and the exploit was delivering other malware to them.

Those sites weren’t all put up by the country that attacked Google. That exploit was put up by organized criminals who knew they had a new round of ammunition to go after their primary targets –companies with customer information or credit card numbers they could quickly turn into cash.

To summarize, APTs aren’t relevant to everyone. But targeted attacks are.

Websense Security Labs has been on the forefront of examining APTs in the wild and have charted the emergence of these exploits. You can learn more about them from my colleague Patrick Runald, one of our senior security research managers, in a recorded webcast.

ISF Annual World Congress is just around the corner. It is an opportunity to exchange ideas and discuss the challenges of the key information security issues that we all face around the globe.

This year I’ll be discussing how public and private sector organizations are facing an escalating challenge in achieving compliance with the number of mandates and requirements that exists.

Most multi-national corporations are struggling to keep up. They are faced with a range of regulations and standards that are recommended or mandated by various groups in different regions.  And they need to demonstrate effective corporate governance and accountability to shareholders or the equivalent dictates that security policies that are in line with the prevailing threat environment and risk appetite must be established and enforced, and their performance and effectiveness monitored.

In a security context, compliance involves ensuring that the ‘in scope’ aspects of the organization’s processes, infrastructure and human and technical resources satisfy the various confidentiality, integrity and availability requirements while continuing to perform their functional role effectively. Where the risk of failing to meet the requirements is too high, controls must be introduced to mitigate the risk.

Compliance is the process of ensuring that the right controls are in place to ensure that this is the case and providing evidence to satisfy the various internal and external stakeholders. This evidence typically includes documentation showing that the controls used derive logically from the requirements and threat models, that they are deployed and functioning as designed and that operational measurements confirm the requirements are met.

The fact is that failure of compliance it too high.  A 2011 survey by Ponemon reports that the average cost of compliance is more than £2 million, but the cost of non-compliance is almost £6 million. While compliance programs are expensive in time, money and effort, the benefits are substantial.

Its been reported by Ovum and others that the costs of Governance, Risk & Compliance GRC programs are increasing as legislation becomes more demanding. Not only this, but the evolving threat environment and increasing pace of innovation mean that controls and compliance must be continually reviewed.

So, enterprises are faced with the considerable challenge of reducing the costs and resources consumed by compliance programs while increasing control sophistication and review frequency.

In my next post, I will present a methodological framework and accompanying software toolset addressing this challenge, drawing on the results of internal and collaborative research projects.

The Information Commissioner’s Office (ICO) recently issued its first fine for data breaches by email to a Council that sent sensitive personal information to the wrong recipients.  The Council in question was fined £120,000 for failing to implement measures to avoid further data breaches, despite two previous warnings.

Corporate email poses one of the greatest risks for accidental data loss, and, due to the sheer volume of email sent by organizations on a daily basis, accidental data losses are almost inevitable.  Common mistakes include inserting the wrong email address, attaching the wrong file, and sending emails that contain sensitive and restricted data to the wrong recipient.

But how do you prevent these losses from happening?  Traditional Data Loss Prevention (DLP) solutions have attempted to address the email issue, but with limited success.  They usually take a long time to start working with any real effect, as intensive tailoring and ‘training’ is needed to help the solution classify data and files that are unique to each organization. 

Also, emails which the system identifies as potential data breach risks are usually flagged to the IT department, which then has to check with the email sender before either allowing or blocking the email.  When combined with the volume of outgoing email generated in any organization of more than 20 – 30 employees, the traditional approach to DLP quickly becomes unworkable, particularly if you are trying to identify the one or two rogue emails.  It’s the equivalent of trying to boil the ocean to find enemy submarines.

Prevention is the cure

Involving individual employees in the corporate security process is the only viable approach to avoid data loss incidents. It is also the only way to turn a DLP solution into a truly preventative tool, as opposed to a reactive tool. 

First, in order to increase user awareness, an effective DLP solution will alert the user before they can send an email that may cause a loss incident.  Let’s take the scenario of an employee who has composed an email, addressed it, and clicked on the ‘send’ button. 

The DLP solution should analyze the body of the email, as well as its attachments and the intended recipient’s address, against a set of pre-defined characteristics to identify potentially sensitive data.  This could include, for example, certain key words in the email body text such as ‘financial,’ ‘report,’ ‘specifications,’ ‘confidential,’ and so on. 

If the DLP solution detects a potential breach based on this analysis, it will override the ‘send’ instruction and present the user with a pop-up alert to inform of the potential data loss and ask how the user wishes to proceed.

The user will have to review the email and choose to:  a) to send the email and its attachments as it stands;  or b) correct the body text or remove suspicious attachments.   There should also be the option for the user to leave a brief explanation as to why he/she overrode the DLP solution’s alert. 

With data watchdogs becoming increasingly vigilant and forceful, it may be time for all businesses – especially those holding customer data – to consider the value of a DLP solution within their organization.  After all, with data losses, prevention is always better than a cure, and also helps to avoid hefty punishments, too.

Are there any significant differences when approaching security between the three cloud service models, SaaS (software as a service), PaaS (platform as a service) and IaaS (infrastructure as a service)?

Different kinds of cloud computing services expose different entry points into the cloud provider and offer to the customer different types of service management operations. In turn, these create different attack surfaces, severity and effects of exploits, as well as different probabilities of a security breach.  

From resilience and availability, mutli-tenancy and data co-mingling, cloud provider lock-in, control of data location, protection of data at rest in the cloud, and compliance to regulations and law about privacy, data protection, cross-border data movement, auditing, etc., there are too many to list in this post, but here’s a quick snapshot about what customers should make themselves aware:

SaaS customers should understand if their applications have been secured to establish best practice guidance such as the Open Web Application Security Project (OWASP) and ensure that application level security controls have been implemented (for example, application-aware firewalling and intrusion prevention systems).

 IaaS customers should understand how resource sharing occurs within your cloud provider – if you require significant scaling-up of provision at the same time as other users of the same cloud, it may risk breaching the capacity of the cloud provider, and therefore affect availability. Also, you should be aware if your cloud provider’s technology architecture uses new and unproven methods for failover and verify what they use for disaster recovery, and you should understand how your cloud provider deletes ‘old’ data, particularly on the cessation of a contract. 

For the PaaS in particular, a cloud provider’s patch management policies and procedures have significant security impact, so the customer should ensure the patching policy is documented.

For a more elaborate analysis on risks and best practices for these see also the Cloud Computing Risk Assessment report by ENISA and the security guidelines of CSA: http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-risk-assessment  http://www.cloudsecurityalliance.org/csaguide.pdf.

In the last post, PART #4: Security and Fraud — Look for what is wrong and know what is right, I talked briefly about the difference of looking for what is wrong as opposed to looking for what is right.  In short, it is an overly simplistic representation of the difference between security and fraud.

Fraud exists in many areas of the business, and I expect it to find its way into IT security.   We’ll see point solutions as the demand increases and as more technology is developed.  But if we look way out in front of us, we can see this as the beginning of a monumental shift, a complete and fundamental shift.  At the extreme, it’s not firewalls and IDS … it’s business profiling.  Every system, application and person is modeled.  Everything gets a “digital persona” that is constantly and intelligently updated to reflect acceptable changes, becoming more and more acute to the specific “condition” of the person or asset.

As a very basic example, we have FBI criminal profilers, who are highly educated and informed people who can offer a perspective of a criminal based on information about the perp.  He’s a 30-year old man, grew up in NY, born in Mexico, his mother was murdered, he was molested, he lived here, he read this magazine, he interacted with these people, etc.

From this and other information, you can begin to draw a picture, predicting potential next steps.  You can predict the threat as well as, in some cases, the tactic.

This profiling already exists in many three letter organizations, military and law enforcement.  It’s a long-standing, proven practice.  So why can’t we do this in the digital world?  The government is already there, but why not business?

It’s brutally expensive.  There is no “meaningful” technology available to the business, and it’s a reversal of today’s security strategy – not something senior executives are going to like.

Nevertheless, it’s coming.  Throughout this series, PART #1 — Security and Fraud: Do we need to be fraud experts?, I’ve been trying to draw a line between security and fraud, yet in time, I’m not sure we’re going to differentiate between the two.

Separating them here was to convey the dynamic that’s occurring.  And in the short-term, security and fraud will be two separate features of the security program.  However, eventually security controls and fraud controls will work together under a common model, building off one another.  Security controls will be tuned to address measurable fraud activities as opposed to being strictly related to threats and classifications.  Fraud will respond to information and visibility that flows in from traditional security so that tools, tactics and modeling of normal activities and related boundaries can be refined – constantly balancing business and threat conditions.

Moreover, risk management will act as the basis of unification, creating a framework that allows effective interactions.  Ultimately, it will all become risk management and fraud management; and all this implies will become another feature within risk amongst threats, vulnerabilities, potential, impact, and so on.

In the long-term, we’re going to see the demand for greater fraud management stem from today’s emerging practices and focus.  For example, DLP is about understanding information assets and looking to control – or at least gain visibility into – how they are flowing.  In time, the focus on information flow will feed into information flow relative to function, access, purpose, and business process.

To elaborate, DLP can help us stop Social Security numbers from crossing from one environment to another, but in the future, it will be about the business processes, operational model, and digital persona of the networks, systems, applications, and people involved in how that information is stored, processed and transmitted.

While today’s security is about stopping the unwanted and undesirable, changes in the threat landscape are going to force security professionals and organizations to focus on determining what is normal.  Fraud is, in many ways, a luxury in today’s IT security and realized through smart people doing smart things with various forms of technology and security services.

Eventually, it’s likely we’ll see fraud detection and management become a centerpiece of security and ultimately, a core function.

In the last post, PART #3 – Security and Fraud: What is normal?, I talked about trends in the identity and access management space in looking at what is normal.  Given the change in threats and the need to accept the risk of more sophisticated attacks, it’s inevitable that more and more attacks will appear as acceptable behavior on the surface.  They may be, however, behaviors that can slowly siphon off valuable assets.  But knowing what IS normal and detecting fraud are not easily done and require a fundamental shift in a security strategy.

Today we look for events that represent a certain type of threat.  We monitor a wide range of systems and types, focus on correlation, limit our exposure through comprehensive vulnerability management, and seek to limit impact via a defense-in-depth strategy.  All of this ties into a meaningful risk management program and very solid practices.  Perfect.  However, the common thread is to focus on generally known conditions.  We have a lot at our disposal to help quantify threats, and that is helping to make very informed decisions about risk.  But, what we’re lacking is the ability to define normal behavior.

Look at the work DARPA is doing around behavior analysis to determine threat potential.  This is directed at everything and everyone.  In simple terms, anything can be a threat at any time, regardless of preconceived judgments.  Today your secretary is nice, tomorrow she’s emailing your competitor all your files.  What characteristics of her activities could have warned you of this potential?  Was it her or her infected systems?

Security is about controls and creating a model to protect assets from threats.  But threats are becoming far more intertwined with our business – its systems, processes, applications, and people.

Today’s capabilities are looking at “threat” conditions so we can effectively apply controls to achieve a balance between threats and assets.  The problem that is quickly surfacing is the redefinition of the threat relative to the controls — we are now looking for what is wrong as opposed to what is right.

Financial companies do this naturally, and I have received numerous calls from American Express looking to make sure that the ticket I purchased in Rome was valid. A great service.  

Now the question is — how do we tie that type of fraud detection effectively into the IT security program?   It’s a huge shift and in a direction away from the current direction of today’s developing technology.  However, with the change in how threats are manifesting themselves, it’s reasonable to see fraud becoming more of what security organizations will focus on.

Up next, I’m going to jump forward to highlight a potential direction I suspect will materialize in the coming years.  It’s going to require a leap of faith, but it’s building on what has been discussed so far and taking it to a long-term vision.

In the last post – PART #2 — Security and Fraud: It’s all about the threats – I talked about threats.  The community of threats is growing and there is a substantial increase in the number of sophisticated threats that have historically represented acceptable risks.

Unfortunately, despite the increase in probability and impact, organizations are still forced to accept expanding risk because the costs to address them are greater and technology isn’t keeping pace.  As a result, we must acknowledge they are among us and look more closely at what is normal – hence, increasing focus on fraud.

Logging and monitoring is a very simple example that’s being discussed a lot.  It’s nothing new, but the increased popularity of this approach is indicative of this shift in philosophy.  Logging and monitoring is a staple of security for obvious reasons.  A part of monitoring is looking for unauthorized access or multiple failures to successfully authenticate and applying controls to limit, for example, password guessing through lockouts and the like.

Today, the discussion surrounding monitoring involves greater sophistication.  When is Alice logging in?  Is that a typical activity?  How many times has she accessed the system in this manner?  Did she just log in from her home and then three minutes later from her desktop?  Are her authorized activities consummate with her job function and predictable relative to the business cycle?   This is one small example — and some people employ versions of this type of detection.  As a result, I’m seeing a huge groundswell in more analysis of what is “normal.” 

I was speaking with the CISO of a large company who told me, “We have a good capability to determine a potential security threat – our firewalls, IDS, proxy servers, and other controls are tuned and effective at alerting us.  However, we’re seeing an increase in certain attacks (referring to APT-style scenarios).”  He paused, and then said, “What is normal?”  

He didn’t mean what others are doing or what are normal practices; he meant what IS normal … how do you define not only the expected “behavior,” but also how do you define the envelope, the line you draw in the sand that constitutes divergence from the expected?

Interestingly, I’ve been trying to generate this type of discussion for years.  Most folks looked at me with confusion, as if asking, “Why would you suggest something we can’t do, Jim?”  I think the reality is that for the last several years, people have been focused on compliance, vulnerabilities, and managing the daily onslaught of malicious attacks picked up by security controls, such as IDS and monitoring.

Although there have been plenty of attacks and events to keep us busy, there has also been a substantial increase in far more nefarious activities that have been slipping under the radar, making detecting fraud more desirable and important.

These advanced threats are becoming far more prevalent and having far greater impact.  Simply put, we’re not perfectly prepared to address them.  Not because we’re incapable – it’s simply a matter of risk, money, resources, and technology.

As threats become more sophisticated, the processes to deal with them must also increase in sophistication.  Sophistication equals expense.  Oddly, just as security is making headway with the business in justifying existence and value, the threat is advancing and making our “proven” controls seem, well, ineffective.  Ironically, most security controls are very effective.  But again, the threat landscape is changing and creating a more complex environment.

Up next, I’ll share more about the nature of fraud and the difference between looking for what is wrong, which can be infinite, and looking for what is right.  The latter may be more finite, but far more difficult.

BT has been named as one of only two providers of “comprehensive services” in “Market Overview: Managed Security Service Providers,” a new report published by Forrester Research. Inc.

Forrester rated 24 multinational vendors that provide outsourced security services, such as log management, threat intelligence, content security, policy/compliance and vulnerability management.  BT was ranked in the report as one of the highest rated Managed Security Service Providers (MSSPs) for its breadth of services.

The report highlights the changing nature of MSSPs, pointing out that, “MSSPs are not just managing devices; they also provide insightful analysis that can help with business decisions.” The Forrester report identifies the readiness of chief information security officers to outsource their security and that while, “…security spending stayed flat for the most part in 2009, Forrester estimates that the managed services grew by roughly 8 percent.”

As well as highlighting BT’s breadth of services, the report notes BT’s “excellent penetration” throughout Europe and the UK and points to its expansion with “a number of acquisitions recently in the US.”  The report also highlights BT’s “good integration of consulting services with managed services.”

Learn more about BT’s managed security solutions and other security offerings.

Cloud computing is a hot topic at this week’s RSA Security Conference in San Francisco.  The amount of time the conference has designated to discuss, explore and debate the numerous security issues surrounding cloud computing is proof positive that more business – and supporting technologies – are taking place in the cloud.

But as more business technologies utilize cloud computing, new opportunities have emerged for hackers and cyber criminals to exploit vulnerabilities and profit from business applications using outdated security solutions for protection.  In short, the evolution of business technologies using cloud computing means that security solutions must follow suit – now.

Rapidly changing security needs require the benefits and advantages that Software-as-a-Service (SaaS) and cloud computing provides.  Security providers that don’t leverage cloud technology are quickly becoming antiquated as all technology – business and security – moves into the cloud.

Using SaaS or cloud computing provides security technology with distinct technological advantages, such as making security updates and code changes instantly available to clients.  In addition, new security technology needs to be developed specifically for the protection of business conducted in the cloud.  The technology landscape has changed and security needs to keep up by including cloud security needs and requirements at the forefront of the development process.

Breach Security is working with partners, such as Akamai, to provide web application security in the cloud.  For example, when deployed with Akamai’s Web Application Firewall service, Breach’s WebDefend Global Event Manager is the first web application security management solution to defend against global application security threats by enabling customers to make distributed cloud and data center defense-in-depth architectures operational.

Breach and Akamai are guarding their clients against security threats in the cloud.  Are you protected?

Sanjay Mehta has more than a decade of experience driving revenue growth and strategic business opportunities at Internet security and technology companies. As Senior Vice President, he is responsible for overseeing Breach Security’s go-to-market strategy, expanding the company’s channel and maintaining and growing its existing customer base.

For organizations that process, store or transmits credit card data, achieving PCI compliance is causing them to evolve from using a periodic security checklist to employing a continuous process to achieve and maintain a state of security and compliance.  For the security practitioners, this has certainly been a great way to connect with the rest of their organization and explain the risks related to data compromise.  However, now we have the challenge of determining what steps we need to take to meet the compliance requirement while making our networks and systems secure as required.

The PCI Security Standards Council recently released the Prioritized Approach to pursue PCI DSS 1.2 compliance with its six milestones.  Any vendor who provides some sort of PCI compliance-related solution will no doubt be working to implement this approach into their solution in the near future, if they have not done so already. The prioritized approach is a roadmap to meet PCI compliance, but all requirements must still be met.

Although many examples can be drawn upon in the 12-requirement structure, let’s examine Requirement 6 — Develop and maintain secure systems and applications.  And more specifically, let’s look at PCI DSS Requirement 6.6.

For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:

• Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes
• Installing a web-application firewall in front of public-facing web applications

Prior to the release of the final DSS, this was probably one of the most discussed new requirements that merchants and service providers would need to comply with.  Initially, it was thought that the requirement would include all three — manual application assessment, regular use of automated assessment tools and installation of a web application firewall.  This is in addition to the requirement for a code review before a custom application goes into production and whenever any changes are made.

In a perfect world where resources are truly limitless, an organization would do all three and would always implement a layered or defense-in-depth approach.  However, “all of the above” is typically not a practical option for most organizations because trying to implement all three elements often brings other complexities, not to mention an increase in cost and resource requirements.

So let’s take a quick look at the type of analysis typically done when we are forced to choose one method over another.  The first option is a manual web application review and assessment. Assuming you select a reputable professional services organization, this is a good option since it is likely to proactively catch the flaws in an application before cardholder data is compromised. This is especially true if the flaws are complex, requiring a sort of connect-the-dots approach, and should be performed just prior to the application being put into production and made publicly available.  For this and other reasons, a competent human can often find flaws that an automated solution cannot.  However, this option is more costly, especially when an application frequently changes.  The testing procedure does allow for this assessment to be performed by a qualified employee of the company who is independent of the web development team.  Certainly, this makes cost much less of an issue, but typically such resources are scarce within organizations.

An alternative to the manual web application assessment is to use an automated tool or service. Only recently has this become a more viable option, as web application assessment tools have largely required a human with advanced knowledge of web application security to tune them during the assessment of optimal results.   A few service-based or cloud-computing options have emerged recently for automated web application assessment.  For an organization that does not have the in-house expertise and needs to perform these web application security assessments on a regular basis, these services are a good option and more cost-effective as compared to the manual approaches discussed earlier.

The service-based approach allows for the automation of repeatable techniques used to identify the most prevalent vulnerabilities, identifies vulnerabilities of syntax and semantics in custom web applications, performs authenticated crawling, profiles the target application, and ensures accuracy by reducing false positives and false negatives through automated testing.  Nonetheless, there is no “silver bullet” to detecting web application vulnerabilities.  Even when using an automated solution, there is still a need at times to perform source code analysis, manual assessment or on-site penetration testing.

The third option is to deploy a web-application firewall (WAF) in front of all publicly facing web servers.  This is also a fairly new technology, and it can be a good, cost-effective option for an organization with a small number of web applications that are not overly complex and dynamic or don’t process a high volume of transactions.  However, the technology and the hardware it runs on are relatively expensive and as best practice, it is not recommended to deploy a large number of web applications behind a single WAF.  In addition, it can be quite challenging to properly configure a WAF to detect and block all malicious traffic that the PCI requirement mandates without breaking some critical functionality along the way.  And with the current move towards cloud computing for all types of applications, the downsides to deploying a WAF are further amplified.  A new option is to combine the benefits of web application scanning to dynamically update and configure the WAF to block for new threats as the application changes. 

Finally, with all these tough choices on the road to PCI compliance, organizations of all sizes really need to look at compliance holistically rather than trying to solve each requirement independently with decisions based solely on which option is least costly.  Organizations need to understand which solutions will meet their needs and partner with providers who can help them meet the PCI DSS requirements effectively.