Sorry to be the bearer of bad news, but DiD can actually make the job of an attacker far easier than it otherwise would be, depending on how it is implemented. Here’s why: as the complexity of the data that is processed increases, it becomes easier for an attacker to introduce an exploitable vulnerability. Therefore, when an attacker is culling the potential target list, they will focus on the applications that process the most complex data. Anti-virus applications are a pretty good fit.

There are companies that implement as many anti-virus products in as many places as their budgets will allow because they think this strategy will keep them safe. They’ve got anti-virus software on workstations, email gateways, proxy servers, network attached storage, mobile devices, messaging, gateways, FTP and HTTP traffic analyzers, and soon enough, they’ll have it on any other technology that stores or transmits files. This strategy gives the attacker a path into each of these systems and allows them to bypass each segmentation layer that may exist within the network. This strategy also makes end users feel invincible, and often leads them to participate in more risky online behavior. When a false sense of security is established, a user may use the same machine to perform risky online behaviors that they use to perform financial transactions, putting sensitive personal or corporate data at risk.

So, what security measures will work without providing additional opportunities to attackers?

Patching the underlying error within the code is the easiest way to keep a vulnerability from being exploited. This process increases security without increasing the amount of code an attacker can interact with. While it is the most straightforward solution, many organizations fail to quickly patch vulnerabilities because of time constraints, management issues or because the patch causes a mission critical application to fail.

Virtualization can provide a computing platform where dangerous operations can be performed and relatively little effort expended to revert the virtual machine to the exact state it was before dangerous actions were performed. The biggest danger with virtualization is that attackers can leverage vulnerabilities to move between the virtual machine and the host machine. As long as the virtual machine software is kept up-to-date with the latest patches, then an attacker would have to use a zero day exploit.

Another effective strategy is to remove infrequently used features from software packages. In general this approach is not commonly employed because software developers feel the need to maintain backwards compatibility, a tendency that is driven by end users who want to be able to access and manipulate historical documents. Here’s a workaround: include a separate program that updates documents produced by outdated versions of a program to the newest version. This enables the backwards compatibility that some end-users desire while keeping the main program lean with regard to rarely used features.

The bottom line is that DiD increases the attack surface available to an attacker and can lead to assumptions that further increase risk to an organization. When implementing a security strategy, it is always preferable to limit the amount of code that processes potentially malicious data.

Ryan Smith
Chief Research Scientist – Accuvant LABS

1. There is truly a need for the application.  There must be an honest business need for the application. If not, organizations should seriously question the decision to use it. This must be carefully considered as every application chosen to support an enterprise-level need increases the overhead of an organization’s IT staff in terms of security and management responsibilities.  Many things are “nice to have,” but, at the end of the day, they simply decrease an organization’s security posture and tax already stressed resources.
    
2. The application can be thoroughly supported by the vendor or with available third-party resources.  Before using an application, the organization should determine how well they can support that application. It’s not wise to tie the success of an enterprise to an application that is overly difficult to manage or maintain. If the application does not have active vulnerability discovery and remediation support, requires management and support overhead that the organization cannot supply, relies on program or system support that negatively impacts the organizations business continuity management program, or contains areas of management and/or security vulnerabilities that cannot be sufficiently addressed using available native or third-party solutions, then the use of the application is likely not a good choice. Too often, we become fascinated with the shiny new car and forget to consider if we have the ability and money required to keep the car running.

Examples of applications that companies should be concerned about include social media and older legacy applications.  These show both ends of the software spectrum – the new and the old.  Both, however, have concerns that must be addressed before they are allowed into the enterprise.

Social media is a rapidly expanding area, and, in many cases, these applications can definitely have legitimate business uses.  However, organizations should consider the dangerous concerns that social networking applications present concerning unauthorized data loss, loss of worker productivity, bandwidth and system resource consumption, and possible infection vectors for compromised code and malware.

Older, well-known applications are often used in favor of newer versions of the same systems.  Companies must consider that the cost savings made in not upgrading to newer versions may be offset by inherent security risks. Widely published and well-known security vulnerabilities contained in these programs can be easily compromised using tools openly proliferated across the Internet.  Also, the software may be at the end of its support lifecycle or tied to older hardware that is no longer easily available for replacement.  Older protocols and operating systems may have a legitimate business use, but, given the wide variety of more secure, supported, and commercially viable options available, the continued use of these products are likely more of a risk than benefit.

What litmus test does your organization use to determine whether or not to deploy a specific application in your environment?

Chris Gray
Senior Risk and Compliance Management Consultant

Originally, rootkits started off as replacements for system programs that might show traces of an attacker.  These replacements had additional code added into them to prevent the legitimate system owners from seeing the traces an attacker had left behind.

Companies developed software to detect the rootkits’ presence so that they could combat them. These pieces of software took simple cryptographic fingerprints of legitimate binaries and periodically compared them against the installed software.  If a single bit of the file was changed, the fingerprint was dramatically changed. As a result, these tools were extremely effective in detecting rootkits.

Unfortunately, as rootkit countermeasures matured, attackers also evolved their tools. All of the programs that could potentially show traces of attacker activity relied on a central piece of software: the kernel.  So, attackers found ways to modify the kernel to hide their traces. They were able to combat the signature-based anti-rootkit technology, which marked the start of a trend that continues to this day – the high-tech game of cat and mouse. As software has continued to evolve to meet the needs of rootkit detection by staying up-to-date with the latest trends, rootkits have continued to evolve by delving deeper into the system.  The trend went from modifications of system programs, to modifications of the kernel, all the way to modifications of the system BIOS and leveraging processor virtualization features.

Computer hardware manufacturers have been pushing Trusted Computing out incrementally over the past few years. And, Trusted Computing could turn out to be an end to the game of cat and mouse. However, if history has anything to say then it will just be another turn in the game.

Ryan Smith
Principle Researcher – Accuvant LABS

But, here we are, nearly a year and a half later, and a recent healthcare survey conducted by the Healthcare Information and Management Systems Society (HIMSS) found that many hospitals, behavioral health sciences organizations and doctors offices, and their business associates are still unprepared to meet the new HITECH provisions. Why? Because the impact of HIPAA HITECH is far reaching, and can be overwhelming to businesses that fall within its scope.

Understanding the provisions and implications is the first step in achieving compliance. It is also a necessity if you’re going to build policies and practices that adhere to HIPAA/HITECH, and potentially secure some of those stimulus incentives. Here are what I deem to be some of the most important requirements:

• All of the elements of the HIPAA Security Rule. While the Final Rule has been in place since 2003, many organizations took a “wait and see” approach to fully implementing these standards for protecting electronic protected health information (e-PHI). HITECH should be seen as an opportunity to revisit the overall alignment with HIPAA security and improve current security practices.
• Under HIPAA/HITECH, business associates of covered entities such as health plans and providers are subject to HIPAA privacy and security rules. As a result, those associates are now required to implement appropriate safeguards. In addition, covered entities must now re-evaluate the way they manage contractual relationships with these entities to make sure that all patients are protected.
• The ARRA requires the U.S Department of Health and Human Services (HHS) to audit covered entities and their business associates regarding HIPAA privacy and security compliance, and to formally investigate a covered entity or a business associate upon receipt of a complaint. Under the ARRA, penalties can range, depending on type of violation, from $100 to $50,000 per violation, with a cap of $25,000 to $1.5 million per year for violations of an identical requirement during the same calendar year.
• The HIPAA security standard did not previously include explicit breach notification requirements. Now, individuals affected by a breach of the privacy and security of their e-PHI must be notified within 30 days after HHS issues guidance. Breach notification applies to covered entities, but also extends to their business associates.

The bottom line is that regulation complexity continues to increase, combined with stiffer penalties and disclosure requirements for breaches. It is imperative that healthcare participants understand the implications for their organizations and respond appropriately.

Evan Tegethoff
Solutions Architect – Risk and Compliance Management

There’s one major problem with this “throw money at the compliance requirements” approach. It does not necessarily make companies more secure. GLBA, for instance, requires that organizations protect their financial data, but it does not address most forms of privacy-related information or intellectual capital. PCI is driving companies to spend entire annual IT budgets on point solutions to address specific elements of the Data Security Standard. Unfortunately, with all of these requirements and costs, many of the organization’s other security program elements are pushed aside, leaving much of the company’s sensitive data (not related to cardholder information) with a much less secure posture. HIPAA protects medical privacy information around patient care.  It does not, however, require many other important elements of a well functioning security program such as effective vulnerability management and risk-based decision making. Sarbanes-Oxley Section 404 assesses the effectiveness of internal controls around financial information, but beyond this scope, the security environment is largely ignored.

With all of these competing demands, companies are spending incredible amounts of money to achieve compliance, focusing on the checklist of required controls to avoid fines and reputational stigmas. Unfortunately, in addressing the specific goals of a specific regulatory requirement, the organization misses out on implementing a complete and well functioning security program.  Rather than drive security strategy and architecture, compliance should instead be viewed as a result of an overall approach that ensures a proper data lifecycle – proper data classification, proper data collection, protection, storage and disposal. This distinction is critical since, in my experience, companies that do not adopt the viewpoint of proactively addressing proper data lifecycle rather than simply treating specific issues usually end up in a perpetually cycle of reactive fire-fighting.

Here’s a real world example to illustrate my point. One organization, a retail company with thousands of remote store locations, was aggressively addressing PCI requirements and spent a significant amount of money on point solutions to achieve compliance. Late in the effort of checking off all the PCI DSS compliance boxes, the organization, wisely, took a moment to begin an inventory of all valuable data that resided in their systems. One issue that arose was the presence of unencrypted data elements that could, together, be used to establish user identity – a definite risk for privacy violations by most state data protection and breach notification legislations.  This information, however, was not a PCI issue, and it was shelved for remediation at a later date.

Unfortunately, before the changes could be implemented to address the issue, a physical breach occurred and the information was lost.  An immediate assessment took place, involving external expertise to identify legal and regulatory requirements to address breach notification costs, required notification communications, and steps to address customer concerns such as credit reporting agency support to provide ongoing monitoring of credit-related issues to affected customers.  Total cost?  More than a quarter-million dollars to perform extensive privacy reviews, and nearly the same amount in external counsel fees and lost internal manpower hours. PCI fines are sometimes extensive, but agreements can often be reached with the acquiring bank(s).  Shelving that real risk in favor of concentrating on compliance had a much more immediate, and likely expensive, price tag.

So, what is the lesson learned here?  This situation should have been addressed by first pausing a moment to understand the totality of the problems before spending a cent on point-in-time, point-of-presence fixes. The second step should then have been to understand what solutions, from a conceptual point of view, needed to be implemented to mitigate the risks rather than just focusing on a checklist approach.  Then, with risks identified and minimized through data lifecycle management, the scope of “real” work could have been reduced, and technology and process implementation could have been relied upon to truly secure the enterprise.

I guarantee that following a risk-based approach rather than a compliance-focused approach would have resulted in far less expense, greatly reduced the amount of time lost reacting to an emergency situation, delivered effective protection of carefully researched and identified sensitive data, and provided compliance with specific PCI requirements as well as other applicable regulation and standards.

Chris Gray
Senior Risk and Compliance Management Consultant

Do you really understand the true risk to your sensitive data and critical systems? If not, it’s time for you to do a little soul searching and find the answers to some really important questions, such as “What really matters to my organization from a security perspective?” And, “Where are we failing to secure our critical assets?”  Given the inability of most organizations to apply adequate time and/or budget to simultaneously tackle every potential security issue, you really need to answer these questions so that you can identify and address your truly critical concerns first.  I’ve seen too many organizations run around in circles trying to secure the next items on their radar – an approach that more often than not turns out poorly.

Here’s what I recommend: use risk to determine the priority of your security initiatives. Take a systematic and effective approach to your security program by first understanding the business drivers in each of the business units. Don’t know where to start? Ask yourself, “How does this unit make money?” Although a bit simplistic, this is a great place to start. From here you should be able to identify mission-critical assets – those are the assets required by the critical systems you just identified.

Once you have identified critical systems and assets, you now know what to protect, but from whom? And what? Categorize and determine the capabilities of the most likely threats you have to these critical systems and assets. Then, determine the vulnerabilities you have in your existing security controls and identify the effort required to exploit these vulnerabilities. Then, start tackling the risks that could most significantly impact your enterprise. Sound like a lot? In all truthfulness, a risk-based approach – especially if legal and regulatory requirements are a concern- is the most efficient way to gain accurate visibility into your current state of compliance and identify what steps are required to mitigate gaps. And, if you need help, check out our new Information Security Risk Assessment service.

Once you’re headed down this path, it is natural to wonder if you have too much or too little security and if you’ll know either way. And that’s great – at least you are considering both ends and that means balance. It is important to understand that critical systems and sensitive data are not the only assets of your company – so is money and time. There is such a thing as too much security. The spending of resources on security improvements should be limited by the value their implementation brings to the protection of other assets (capped by asset value).

You should put enough effort into security to reduce the real, validated risk to an acceptable amount. When security efforts are a hindrance to your business processes beyond the value of what is being protected, your company has too much security in place.

I’ve just thrown a lot at you so let me give you a good rule of thumb. When you start worrying more about how much you are spending on security than you are about your assets being compromised, then you are spending too much. If you are still worried about the protection of your assets over security spending, you have put in too little.  Re-evaluate, re-address and re-implement.

Have you been taking the right approach? Can you demonstrate that to management?

Doug Landoll
Practice Director – Risk and Compliance Management

Is the idea of taking an organization’s environment mobile such a silly thought? A far flung fantasy? Perhaps surprisingly, not as much as one would think. Certainly, the thought process above is a bit exaggerated. People don’t really watch Dr. Who. But – organizations are considering this transition. Recently, Accuvant was approached by a client with this very type of request. We were asked what it means to lose the workstation, to leave workers to their own devices, to place the users on the outside of the kingdom. What are the security risks? What are the security savings?

What is more profound is the frequency in which these types of requests are beginning to materialize. Embattled with their perceived state of security, the ever-increasing cost of system management, an inability to achieve a reasonable level of control and grandeur dreams of slashing overhead costs and reducing risk levels, it is easy to understand why many organizations would consider throwing up a white flag and letting the castle gates down. Corporate America, awash with data centers that are due for a refresh and upgrade in the near term, are tantalized at the prospect of redefining the definition of “security at the edge”.  

So, what’s an executive tasked with the protection of information supposed to do?  Retreat to the inner core of the network and build a wall around the prized corporate jewels?  Legions of employees, even those inside the corporate office, would join the ranks of roaming mobile warriors with remote authentication tunneled through controlled entries, unprotected by the prized perimeter security strategy and treated like the savages of the unmonitored Internet to which they are relegated.  All this, as a result of simply wanting to achieve lower operating costs and increased security control; greater visibility and scalability that can be achieved with a minimal infliction of pain.  

How far can this idea go? Do we even need a network? Wasn’t ubiquitous computing the solution? Clearly, some of our clients believe so. They are dissolving the perimeter, packing up, sending user applications to the cloud, and moving their valuables to the collocation data centers. They are going to divest themselves of the end point as an asset and replace it with a comprehensive NAC strategy that enforces corporate standards and policy.

On top of that, is it possible to have our cake and eat it too, i.e., a secure work environment layered on top of an uncontrolled desktop environment? Virtualization presents such an opportunity. No longer does a physical machine have to map directly to the job. Although the segregation of a network into distinct zones defined by the required security controls and sensitivity levels is nothing new, access to basic functions and services such as web browsing, email and standard applications can be provided on a low-risk network while activity critical to those business functions that handle critical data are contained on a highly secured controlled network. The virtual machine is defined as a secure environment sharing data across its own encrypted private network isolated from the system on which it sits.

Of course, this leaves us with a system that must be configured as such. Didn’t we just try to get away from this problem? So how do we create a dual environment without managing the system it sits on? We take classic security controls, a preconfigured work environment with the applications and data needed, apply policies, monitoring and auditing as needed. Then, you lock it all down, encrypt the whole mess, toss it on a portable drive, and make it boot. Some call it a “system on a stick”, where access is given to those in the need in a form that goes everywhere. Controlled centrally, the physical device is no longer a risk or cost for the organization. To the controlled environment, it always looks the same regardless of where in the world it travels. Loss and theft of a drive becomes irrelevant and relegated to a cost of the device rather than a loss of critical data with native encryption. Even business partners who need access to certain forms of data can be issued devices with their own sets of policies and controls. The need to allow data to leave the protected castle becomes a thing of the past, bringing those with the need inside rather than let that which is needed out.

As I mentioned previously, this concept is nothing new. Centralized server environments with virtualized desktops already exist and serve their function quite well. There is, of course, the cost of centralized hardware and pipes large enough to handle LA traffic during rush hour. Offloading the operating system to a USB drive allows for the use of cheap common hardware for computing power and only the bandwidth needed to serve data located centrally.

So USB drives with isolated encrypted virtualized operating systems and critical data centrally stored and controlled. Does it work? Does it stink? Please do tell. What am I missing? Any war stories to share? We would love to hear.

Chris Morales
Accuvant Solutions Engineer

There are two basic architectures used by WIPS systems. First is the overlay architecture. This uses specialized access points that are deployed throughout the enterprise in order to provide ubiquitous WIPS coverage and triangulate any place that wireless attacks might come from while also monitoring the wireless infrastructure. Being highly specialized like this gives a great deal more information as to what’s going on in the wireless network. The second architecture that is used is the time-slicing or you could also say integrated architecture. This approach uses regular AP’s which are deployed and serving WLAN clients and for a few milliseconds take a ‘slice’ of time to scan for wireless attacks and to monitor the wireless network.

There are costs and benefits to both of these architectures in WLAN design. For the overlay architecture there is the obvious cost up front of purchasing additional specialized access points to cover the entire RF footprint of the enterprise. There are also several benefits to this architecture, first the ability of the overlay architecture to constantly monitor and if necessary to mitigate attacks and rogues in the network gives it a big advantage. The vendors that have this kind of architecture usually are able to see in much more detail the performance of the radio spectrum that is in use as well and this gives them an advantage in being able to identify when there is interference or other performance problems with the WLAN. The downside to this is that it requires more knowledge on the part of the wireless engineer who is managing the network to be able to identify why the performance is suffering or where the wireless attack could be attempting to exploit a weakness in the WLAN network. This complexity can also be difficult for someone who has to work with many other technologies outside of wireless. Overlay WIPS architectures are also commonly used to enforce a no-wireless policy that an enterprise may have because they do not allow any clients to connect and do not provide network access.

The time slicing or integrated architecture has the advantage that it can utilize existing AP’s that are deployed in the enterprise WLAN. This lowers substantially the cost of a WIPS deployment, especially where the main thrust of the deployment is to assist in client monitoring and rogue detection. As this architecture is normally integrated into the WLAN architecture, the management tools used are also usually a part of that WLAN’s management system. This gives the wireless engineer less tools to learn and potentially a more streamlined way of monitoring and being notified of problems with the WLAN. The downside to this is that as the AP is doing dual jobs, monitoring the network as well as servicing clients, it may end up in a situation where it does neither job very well. The basic operation of this kind of architecture is to spend part of the AP’s time servicing clients and part scanning the network for problems. In the case of voice or video usage in the WLAN a very big factor in them operating well is the latency of the connection. When the AP has to stop and spend part of its time to do a scan, then it will by its very nature introduce latency to the network and affect those protocols. When the AP is scanning there is a problem in that it may miss a wireless attack or network performance problem as it was not scanning but servicing clients when the attack started and also there is a problem where it cannot constantly try to mitigate the attack as it has to go back to servicing clients.

I would encourage strongly anyone who is thinking about implementing a WLAN in their enterprise to consider the benefits of a WIPS solution. As WLAN technologies mature and become relied on by your employees to do their jobs, being able to properly monitor and manage the performance of the WLAN also becomes critical to the business. WLAN’s have become much more secure in recent years with the adoption of standards such as AES encryption and 802.1X authentication for clients, but there continues to be a challenge in properly managing and preventing attacks on the wireless infrastructure. I would also suggest that the overlay architecture will provide the best value for situations where the WLAN is critical for business processes. There are vendors in the market now with overlay systems that are easy to setup and use and also vendors that provide a large set of additional features and enhanced functionality that will enable someone who needs complete control to monitor every aspect of their WLAN.

Chris Lyttle
Principal Wireless Security Consultant – Accuvant

When making a decision between competing products – assuming there were no considerations beyond which technology performs best, solves the problem or enables the business most efficiently – then a ‘best-of-breed’ approach would clearly be preferred over a product suite. In fact, that approach is Accuvant’s preference when presented with a ‘perfect world’ scenario. However, we don’t live in a perfect world. If we did, John Elway would be getting ready to lead the Denver Broncos to a record 15^th straight Super Bowl victory, and he is not. In this world, we need to consider things like budget constraints, technology interoperability, training investments and the New England Patriots.

While I don’t think an organization’s security strategy should be dictated by cost considerations, there is a tendency towards overkill in the technology sector, especially in our space. Time and again, we’ve seen ant-sized problems that dozens of manufacturer salespeople are ready to sell a sledgehammer, a trebuchet or an ICBM, with the only question being which color trebuchet is best suited. (Of course, I am not referring to any of Accuvant’s partner reps here, all of whom are saintly.)

Instead, I am presupposing that a best-of-breed approach is more costly than the adoption of a product suite, which I think is safe. What I’m not saying, however, is that individual point solutions in a suite are inferior technologies to those offered by independent, focused, niche players. In fact, even when that is the case, it is usually short-lived as larger companies – the big fish – acquire the innovators – the small fish – and incorporate them into their solution suites. Data leak prevention (DLP) technology provides a great example of this dynamic, as demonstrated by the flurry of acquisitions over the past few years.

DLP also offers an example of other factors that an organization must weigh when making a technology decision. If we assume – solely for the sake of argument – that all DLP solutions are equally capable and that they all cost the same amount, then it is safe to say that the client’s decision will be based on its relationships or the investment it has made in the “big fish” company. If the client has made a significant investment in EMC and RSA, for example, then the RSA DLP solution will likely win based on its interoperability with other EMC/RSA products, the client’s (IT staff) knowledge of RSA solutions, and probably even volume pricing arrangements in place with EMC/RSA. Again, I am not saying all DLP products are the same, but I do not think an organization would be well-served by comparing DLP products without considering how each DLP product fits into the manufacturer’s solution suite.

To sum up, I think there is a place for both a best-of-breed and a product suite approach. I also think a good reseller partner should take the time to understand its client’s needs, be knowledgeable and current on manufacturers’ products, consider the advantages and disadvantages of both approaches, and only then arrive at and offer the best possible solution. “Is the trend towards comprehensive security suites a positive development, or does Accuvant prefer to assemble a solution from various best-of-breed products?” Yes, absolutely.

Dan Wilson
VP Partner Alliances

For better or for worse, Microsoft has taught the industry to patch once a month. But, most of Microsoft’s patches released on this monthly cycle deal only with the various Microsoft Operating Systems and fail to address vulnerabilities in primary or secondary applications or services such as Exchange, SharePoint, IIS, etc. Due to this type of release cycle, and a lack of self education on the part of the administration staff, many organizations are failing to effectively patch the technologies and applications that lie on top of their Operating Systems, such as Oracle databases and desktop applications like Adobe Acrobat. Without a comprehensive patch management program, organizations continue to have significant gaps in their security based on missing patches. 

Honestly, enterprise patch management doesn’t have to be a problem.  Just recently, Microsoft released their new patch management solution, which provided better flexibility to manage patches at the desktop and secondary application level. Additionally, there have been solutions available on the market that enable organizations to effectively maintain operating system patches for not only Windows but other operating systems such as Linux and Unix, as well as primary and secondary functioning applications like SQL servers, MS Office and the various Adobe products. Some even go as far as providing better support for pushing antivirus updates. Many of these solutions also provide the capabilities companies need to maintain consistent hardware configuration settings. 

Just as enterprise patch management is a fixable issue, so is network enterprise configuration management. From a hardening procedure standpoint, organizations spend a lot of time creating their standard system build image and forget to come back and update that image on a regular basis.  A solution that was effective six to 12 months ago will not be effective today, and it will leave a network vulnerable. Standards change and the Internet is not static. Therefore, it’s important for companies to pay attention to ongoing maintenance of standards and policies and make ongoing changes as appropriate. 

As you can see, when it comes to network security the people and processes are just as important as the technology – maybe even more so. I strongly believe that the biggest potential mistake administrators and/or companies can make is not educating their users.

 The majority of recent attacks faced by Twitter and Google are directly targeting the employees and users of corporate networks. Companies that haven’t taught their users the basics of what to avoid can pretty much assume they’re going to get infected by the next big infestation/attack, especially when you couple that with legacy technologies like Internet Explorer 6 as the standard browser they are required to use. Providing ongoing user awareness training and seminars that include real world examples and scenarios is the best way to educate users on their requirements to help keep the environment as secure as possible. 

Companies also need to focus more on using the right resources for the right initiatives. A common mistake that I’ve seen over the past two years happens when an organization buys a Web Application Firewall (WAF) and leverages network operations personnel to implement and maintain the system. Unfortunately they will find out the hard way that they are using the wrong resources. A WAF requires detailed knowledge of the Web environment and application infrastructure, which many network operational professionals do not have. Based on a strong understanding of Web applications, an application level professional or developer would be a better choice for ongoing maintenance of this type of technology – at least from a policy and technology enforcement perspective.

I’d love to hear about the changes your company has made to harden network security. Let me know!

Jim Broome
Director – Accuvant LABS