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.

I know you don’t need me to tell me that the job you have in front of you is a tough one.  Even before the economic downturn increased the likelihood of attacks on your network, and your customers’ personal information, you faced a tall order: to articulate the value that your team brings to your organization.  After all, if you were successful at your job your network was robust and resilient.  But now, as your entire organization charts its way through the remainder of this economic maelstrom, you’re trying to make it all work with smaller budgets, fewer team members, and without the luxury of frequent technology refreshes.

While it’s tempting to throw up your hands and focus on tactical responses, there are some key issues that, as an industry, security vendors should be discussing with you to make your jobs less daunting.  Most are what I like to call “security truths” – things that we know should be addressed, yet which we sweep under the rug to think about another day.

I believe today is the day for us to take these items out from under the rug and address them head on.  What do you say?

Security Truth #1 – Decipher the Jargon

Most of us in the industry rely on jargon to make ourselves sound more authentic.  We use big words and talk the big talk, but in the end, how do you know what we really know, what really makes different, and what makes us, or some other company, the right vendor for you?

The bottom line is: you shouldn’t assess how much you trust a security product or service based on an RFP response alone.  Your trust and confidence that they will support you during ambiguous problems, without hiding behind contracts and formality, is a far better indicator how flexibly they will support your objectives.

Yes, it is true; in the end, most vendors will sound similar, and will be willing to commit technical resources to fill gaps you identify as priority requirements.  While the mechanics of those points will certainly vary, the answers to an RFP questions will rarely, if ever, tell you if this is the company you should work with.

In the end, that trust and confidence translates into how readily your vendor will make exceptions to its own processes and billing caps, because the vendor is doing their own calculation internally on whether they can absorb the cost of that exception on the longer-term value of your business.  Working with a vendor where you are one of their bigger accounts (but not necessarily their biggest) should give you the right mindshare.

Security Truth #2 – Stop Running Fool’s Errands

Assigning blame for a network security breach or zero day attack is a fool’s errand.  It’s human nature to want to blame someone or something for an incident.  But let’s be real:  most security incidents are a result of complexity in products, environments, staff knowledge, and a whole variety of other issues.

There will certainly be situations where an individual makes a brazen mistake and should have known better.  Vulnerabilities where patches were released years ago, yet never installed; temporary firewall changes which aren’t undone; unauthorized new servers added to the network – these are pretty straightforward high-risk activities, and every one is a likely front door to an attack.  Most finger-pointing energies should be channeled towards looking within, at policy, and, more importantly how policy is instituted, executed and enforced because the majority of security policies are far too vague and ambiguous.

Want some clarity?  It will take a bit of work, but it’s not too painful.   First of all the security lead needs to categorize what kind of security organization he or she is running inside the company.  For example, do you define strategy at an executive level, or are you adjunct to conventional IT?  Do you participate in signoff for business initiatives?  Do you control budget for projects in the planning stage, or are you simply told what your slice will be after someone else finalizes the architecture?

Ultimately these sorts of questions drive how much authority you can write into your policy and enforce.   In turn, this will impact whether you can demand certain end-user behavior or if, instead, you need to co-opt other groups (such as HR) into supporting your policy roll-out. 

Security Truth #3 – Monetary Cost is Only One Consideration

Like any other act requiring a purchase order buying a security product or service is typically presented as a matter of dollars and cents.   But is this an accurate representation of its real cost?  I am of the opinion that security purchases should not be presented solely in terms of the technology cost and that incremental demand on staff cycles, from annual vendor training to increased log analysis, be incorporated into a technology purchase’s true cost to the business.

We often encounter customers who have essentially lost track of their network architecture.  This is all but inevitable when you grow by acquisition, or in response to individual projects.  But it is that very complexity, and corresponding lack of adequate controls, which creates opportunities for product vendors looking to fill the gaps.  Buying a product to fix a problem, without exploring whether existing assets or a revised control could achieve similar goals, places a big burden on your staff.

The costs are soft, but they add up quickly.  You need to account for extra recurring time in maintaining the new product, but you also need to anticipate that it will probably impact existing tools as well.  It will require acceptance testing to document how it adds to your policy controls.  It will need space in your data center.

These costs are all perfectly fine if you can point to a specific control or policy statement which is currently underserved.  But it will always be preferable to leverage your existing tools, and the expertise your staff already have, whenever possible.

Now, perhaps none of these ‘security truths’ apply to your organization, or perhaps you recognize your organization in each one.  Whatever your specific situation I hope they provide some points for consideration as you structure your organization to meet the challenges of a recovering business and economic climate.

I look forward to engaging with you to find out what daily issues are causing you most concern and sharing what we see and have learned from being on the other side of the table.   Why not leave a comment below or send a tweet to @SecureThinking!

Cheers,

Jeff

Jeff Schmidt

Vice President and General Manager, Managed Security Solutions Group, BT Global Services