Difficult to configure. Confusing to use. Time-consuming to manage. Set-it-and-forget-it security. These are some of the perceptions of Web application firewalls that can be, in many cases, dangerous to the security health of your organization. Like physical exercise, exercising good security practices requires effort and commitment, but at the end of the day, the benefits far outweigh the costs. This may be news to some, but a Web app firewall is not a set-it-and-forget-it security crutch. Rather, a Web app firewall is a security tool that requires dedicated use. Most importantly, the Web application firewall isn’t a sentient being, it’s a device that, like many of man’s creations, is only as good as the person or people wielding it.

A State of Mind

Security is never a feature you can outright purchase. It’s not a box you can check, or a test you can pass and be done with. This rationale applies to security whether it be for a car, a home, or your Web apps. This is a concept most people can grasp in more physical, trivial day-to-day tasks, but sometimes is lost when it comes to the Web. For example, driving to and from work is potentially very dangerous. However, if you practice, get your license, and drive with caution, while avoiding activities like speeding and texting while driving, you will -in all likelihood – be safe. No one would get into the driver’s seat of a car for the first time and expect passive safety features like a seat belt and airbag to make up for their lack of experience. The same applies to Web app firewalls; there are measures of practice that must be applied in order to achieve security, one cannot rely solely upon passive features to do all the work. Web app firewall users need to be active drivers, not passive ones. Here are some tips to help keep in an information security state of mind, and become an active Web app firewall driver.

Think in Layers

Don’t: Put up only a single obstacle to prevent vulnerability exploits.
Do: Use a Web app firewall as one layer in a multi-layered wall.
Why: Most code in applications isn’t perfect (really, none of it is, but even if it was finding legitimate paths of entry via proper authorization information is possible). This means there are flaws in it that can be exploited by attackers. However, flaws or vulnerabilities oftentimes cannot be easily fixed or recognized. Security should be thought of in layers, with each layer serving its own purpose and no layer being responsible for the entire load. Think of home security; you may have a fence, locks on your doors, and an alarm. A WAF should only constitute a single layer in a larger defense scheme.
How: A Defense in Depth strategy. This type of strategy aims to create a series of backup measures in case one layer fails, which allows each security tool to perform within its functional specifications and not put the entire job of security on one layer. This strategy can also be thought of as a funnel, with broader measures at the top leading down to the most specific security functionality at the base, in the form of a Web app firewall.

Firewall

Block traffic going to all ports other than Ports 80 and 443. This will funnel traffic into those two ports for inspection by the other layers of security behind it. Wendy Nather wrote a piece on why we still need firewalls that nicely explains their usefulness.

IDS

Detection is needed to alert a system admin if and when an intruder is recognized in the application. Being aware of an intruder’s existence inside the app allows for a potential attack to be identified before the attack has commenced. This will give a system admin time to take additional preventative measures to prevent an attack, such as blocking the IP or logging off a user account if its been taken over. This will provide a more general security detection solution that will alert when intrusions occur at the network and system levels, not specifically within an application, as an app firewall would.

IPS

An intrusion prevention system will prevent an attacker from gathering information on your app and sever. It’s essential to prevent hacker reconnaissance by obfuscating information like server type, file extensions, and application or site errors from being easily accessible to hackers. This is again a more system and network level approach.

Application firewall

Finally, your applications will require an app firewall to secure them specifically, as they are valuable centers of information with large amount of traffic going in and out. A Web app firewall can monitor, detect, and prevent malicious traffic accessing applications.  With active usage, a Web app firewall will act as a powerful last line of defense for your Web apps against attacks.

Shrink Wrap Your Security

Don’t: Expect a WAF to be correctly configured for your site out of the box.
Do: Set up your Web application firewall for your specific needs.
Why: Shrink-wrapping a Web app firewall’s security to tightly fit around your specific requirements leaves less room for error. Simply using a blacklist of attack signatures is a good way to get hit by a Zero Day, and whitelisting could lead to false-positives.
How: Set app specific policies that only allow an app to be used the way it was intended. Any vulnerabilities found through penetration testing that cannot be easily remediated should have app firewall policies put in place to protect until corrections can be made to the vulnerable code. Setting some of the below policies in your Web app firewall is a good start to shrink wrapping security.

Input validation.  Configuring a Web app firewall’s input validation policies will help prevent against attacks like SQL inject and cross site scripting (XSS).  Platform-specific exploits can use complex URL strings to gain access to a shell or a Common Gateway Interface (CGI), from which a hacker can easily get a directory listing revealing file structure. Input sanitizing prevents harmful scripts from being injected into your app through URLs or form fields and should be enabled on an app firewall. This should be configured depending on the characters permitted and needed in each individual field.

Use different configurations. Like customizing input sanitizing, if you need to secure – for example – an Exchange server and a Joomla site, do not use the same configuration for both. Just as a house with no windows will need different security than a glass house, different Web apps will have their own security needs that should be addressed independently.

Manage file uploads. If users can upload files, only allow the file types your site uses. This means things like preventing dynamic files from being uploaded if your site only hosts images. A Web app firewall should be configured to block any attempt to upload files that your app or site does not use. Be sure to be as specific as possible by either whitelisting only what you will use, or blacklisting all file types that you cannot use.

Be weary of session hijacking. Set user sessions to timeout when idle for an extended period of time. This will help prevent a user’s session from being hijacked, leading to unauthorized access to sensitive information. Policies can also be enforced so a session can only be used on a single IP address, thus preventing an outside hacker (with a different IP) from gaining access to the legitimate users session because it is limited to one IP.

Request management. You know the areas of your site or app where sensitive data can be accessed, the types of sensitive data, and the types of files that your site is composed of. Make sure access to admin URLs are restricted and requests for sensitive files are blocked by your Web app firewall for untrusted users.

Without security measures in place, hackers will find vulnerable penetration vectors in your Web applications. Imagine your site as a bank; there are ordinary locks and alarms on the perimeter doors, but the valuable goods (money, etc.) are inside a vault. Since you know your Web applications best, it’s up to you to make sure you place locks on all the doors, and make sure you put bigger locks on the more important doors. If you’re unsure what needs to be secured, thoroughly scrutinize and pentest your site.

You’re Never Done Securing

Even after you’ve configured your Web application firewall perfectly and put in place the best security policies you can, there are dangers to be aware of.  Human error, trust betrayal, and organizational challenges pose security threats that are hard to defend against, but are important to evaluate as they pertain to your organization.

Denial of Service (DoS). Made popular by its presence in the media as the attack method of choice by hacktivist groups, denial of service attacks (DoS) have become a major concern for many organizations – and rightly so. DoS attacks rely on a large number of requests to bring down a target site or app.  Casual DoS attacks can be diminished through use of a Web application firewall by limiting the number of requests per second or blocking IP addresses with high request frequencies. Though if you are dealing with very serious and determined DoS attacks, you may want to perform a risk assessment and investigate cloud-scale countermeasures, which will require some organizational backing to make the necessary changes.

Zero Day.  Zero Day attacks are attacks that exploit previously unknown vulnerabilities.  Even if you have tested against every known exploit and have secured against them, new vulnerability exploits will arise that you will not be protected against.  Any attack, even know attack types like SQL injection or cross site scripting, can become major threats if its a zero day exploit.  New exploits are created every day and can be very damaging, though a Web app firewall can be used to preempt them.   When purchasing a Web app firewall make sure it has a strategy for dealing with unknown exploits or a methodology for dealing with attacks that it hasn’t seen before.   Even with an app firewall in place, it’s important to remember that security today doesn’t mean you won’t be vulnerable tomorrow.

Exploiting Legitimate Trust Relationships.  Web app firewalls and security policies can go a long way to securing an organization, but exploitation of trust relationships – whether intentional or unintentional – are hard to defend against.  Members of an organization must be intelligent and prudent about their Web use for the organization to remain secure.  This means not opening attachments from unknown senders, not clicking on strange links from unknown and un-trusted people, and so on.  For example, if a user unknowingly downloads a keystroke logger from an untrusted email correspondant, a hacker can simply lift credentials from the logger and gain legitimate access to an organization’s system – no SQL injection, session hijacking, or complex hacking techniques required.  This example brings to light the human element of Web security; an organization is only as safe as its least secure link.

Test, Update, and Evaluate

Don’t: Have static security or perform one round of penetration testing, auditing, or use being PCI compliant as an excuse to not perform further testing.
Do: Test and audit regularly. Evolve your security plan as threats and traffic trends on your site change.
Why: Security vulnerabilities can arise after a code change, an update or through a new hacking method. Nothing is ever static; the Web is constantly changing, which means that security needs to stay current with changes that occur. New vulnerabilities are discovered all the time, even in major software companies’ code.
How: Stay current with patch and updates; people spend hours developing these for a reason. Stay informed by reading about information security trends, following #infosec on Twitter, talking to peers, and so on. Regularly pentest and audit your apps and sites. Analyze logs and learn from them to make adjustments to Web app firewall configuration.

Log. When first setting up a WAF, use a logging mode to evaluate your site’s traffic. This will give you a sense of where tighter policies may need to be set or where exceptions may need to be set.

Check for false positives. False positives are bad for business. You never want to blocking a legitimate and harmless user who accidentally mistyped a URL or input incorrect characters into a field because security policies are set too tightly. Logs should be checked regularly for errors that aren’t really errors, and exceptions should be added to policies that may be resulting in false positives.

Perform tests. Penetration testing for vulnerabilities in your code will show you what you need to protect against until new code can be deployed to fix it.  Set new policies in your app firewall based on your testing.

Update and patch.   Install updates as they are released.  Deploy patches to secure vulnerable code; it does’t matter if the patch is out if you don’t actually apply it.  If there is an update or patch available to secure a vulnerability, chances are there are people who know how to exploit it.

Web app firewalls can be a useful ally toward greater Web security for those who know how to use them properly.  Whether you’re in the market for a new Web app firewall, or are already a proud owner, understanding that a Web app firewall is a tool designed to be driven is an important step toward increased Web security.

On March 30, Utah’s Medicaid health services was breached by a hacker based in Eastern Europe who stole up to 780,000 medical files – up to 280,096 of which contained social security numbers.  According to Utah Department of Technology Services spokesperson, Stephanie Weiss, the breached server was “A test server and when it was put into production there was a misconfiguration.  Processes were not followed and the password was very weak.”

This week Utah Governor Gary R. Herbert called for an audit of all state information security and data storage procedures – as well as the handling of the information in the recent breach.  It’s unfortunate that it took an incident like this to recognize the need for thorough security audits.

Low-latency Networks for Your Home

A brief overview of the problem of network latency, and how software solutions look to remedy it.

Microsoft Patches and Internet Explorer Woes

Microsoft issued six security bulletins with new patches addressing four critical vulnerabilities.  All four four of these critical bulletins were for remote code execution vulnerabilities.

Of note is a critical remote code execution vulnerability in Internet Explorer.   By tricking a user to open a document in their browser, a hacker could take control of the user’s PC.

The Anatomy of a Hack

Patrick Meenan rolled out his access logs to trace the activities of a hacker who penetrated the forums at webpagetest.org.

Don’t think your site is receiving harmful traffic?  Incapsula recently put together a report about website traffic and its legitimacy, harmfulness, and humanness.  The information compiled came, “from a sample of one thousand website of Incapsula customers, with 50,000 to 100,000 monthly visitors,” their site says.

What did the report say?  51% of all website traffic was non-human.  Of that 51%, 31% of traffic consisted of potentially harmful visitors, including hacking tools, scrapers, spies, and comment spammers.

That means that less your site’s traffic may be less man than machine.

So wait, you’re telling me that of the 10,000 visitors Google Analytics told me I had last month, only 5,000 of them were actual people?

No, actually, the amount Google Analytics told you is more or less accurate about the amount of human traffic, it simply doesn’t tell you about the hackers, spammers, scrapers, and spies that are visiting your site.  These visitors essentially go unnoticed and are invisible unless you look for them.  But how can you prepare and secure your site if you don’t even know what’s actually happening on it?

A Problem of Analytical Proportions

Now you’re probably crying, “why wouldn’t Google tell me these kind of things?!”  Well, the short answer is: they can’t.  When a user goes to a page on your site, their browser makes a request from your web server to send a specific page.  The web server returns the page to the browser with an embedded piece of JavaScript, which is the code that runs Google Analytics.  The code gathers the information from the page opened in the browser and sends it to the databases at Google.  After the information is sent to Google, you can go to your Google Analytics account to access the gathered data.

The problem is that non-human traffic, like scrapers and hacking tools, are visiting your site, but they don’t run the JavaScript used to send the information from the browser to Google.  Since Google Analytics runs on a separate server from your site, this script needs to send the information to the Google Analytics databases in order for a visit to be recorded.

What Can You Do?

You can keep using Google Analytics, or your preferred analytics service, but there are measures you can take make yourself more aware of what is happening on your site.

• Check log files.  By manually coming through your server log files you can see all the traffic that has come to your site.  It may take a little bit of time and work, but spotting bots can be done fairly easily.  Things to look for:
• Suspicious user agents. Users not fetching dependencies like JavaScript or cookies are good signs of a bot.
• Rapid movement. If you notice a visitor has viewed a lot of pages in a very short period of time (i.e. 1000 pages in 10 seconds), that’s a good sign of a bot.
• Bad Requests. If your site is on ASP and you see requests for PHP, a guessing bot is probably making the illegitimate requests.
• Checking for Robots.txt requests.  This is the file that bots will look for and request, by noting the number of requests you will know how many times bots were on your site.
• It’s a Trap!  Setting up traps to catch bots can be done by creating invisible links on your site, which human visitors won’t be able to see or find, but bots crawling your site for links will be able to.  For every time that link is hit, you will know that a bot visited your site.
• ServerDefender VP can track and show you all every request hitting your server.  Real-time logs and monitoring clearly display the names of malicious visitors.  Below are images of what bad traffic looks like versus legitimate traffic.

Microsoft's new IIS 8 Logo

The New IIS and Windows Server 8

In March, Microsoft released beta versions of its latest and much-altered Windows line-up.  While most of the focus was given to Windows 8 for PCs, there is much to be seen in the new Windows Server “8” (the official title is in parentheses for the time being) and IIS 8.

We took a look at the new features in IIS 8 and Windows Server 8 beta (Download the Windows Server 8 Beta) and have put together a breakdown of some of  what’s new and what’s got us excited.

What’s New

A lot has been added or changed for IIS and Windows Server 8.  Microsoft’s continued efforts for cloud integration are apparent, as well as improvements in virtualization, security, and elsewhere.  Here are a sampling of the changes made:

-Server virtualization.  Server 8 goes “beyond virtualization” to offer features for building a private cloud, scaling and protecting workloads, while being more cost-efficient and more secure.

-Multiserver control.  Now, you will be able to control multiple servers simply and easily through a single server.

-PowerShell 3.0.  The newest iteration of the command-line interface provides a comprehensive management platform for servers, storage, and networks.

-Cloud service connectivity.  Server 8 provided flexibility in the cloud, allowing users to build and deploy applications in the cloud or on-site.

Also…

-There is the new Metro user interface.  Optimized for touch screens, tablets, and mobile devices, the Metro UI is one of the most noticeable visual changes, albeit not one of the most useful for the server edition.

What’s Exciting

Since we develop security and performance tools for IIS, our opinion of “what’s exciting” is somewhat skewed.  Below we’ve highlighted some of the best new performance and security features, as well as some other exciting new aspects.

IIS

Centralized SSL Support

Previously, copying and importing SSL certificates was an inefficient process, with each certificate needing to be copied and imported individually to their respective machines.

Now, IIS 8 has Centralized SSL Certificate Support to store all SSL certificates centrally in a file server, allowing the files to be shared by other servers.  This makes scaling easy, since additional servers can all share a single folder, and only this single folder will need to be updated.  The ability to simply copy certificates also means you will no longer need to follow multi-step importing procedures like this.

In short: SSL certificate management is simplified into one shared location.

Dynamic IP Restrictions

Allows users to set up filters to deny access to IP addresses of potentially malicious users.  Dynamic IP Restriction will automatically block potentially harmful IP addresses, making it beneficial in protecting against DoS attacks.

Microsoft highlights the following ways that dynamic IP filtering can be used:

• “Block access for IP addresses that exceed the specific number of requests
• Block access based on the number of connection attempts from an IP address during a specified time period.
• Specify the behavior when IIS blocks an IP address.  Requests from malicious clients can then be aborted by the server instead of returning HTTP 403.6 responses to the client.”

Administrators can set static rules like “block requests from IP address X” or dynamic rules like “block requests from IP addresses with more than X simultaneous connections” to restrict access.  There’s even a “logging only” feature that allows admins to set rules that log what would happen if the rule was in play, but do not actually block any requests.

Using IIS 8.0 Dynamic IP Address Restrictions

In short: Dynamic IP Restrictions can be set up to block potentially malicious IP addresses and can help thwart DoS attacks.

FTP Logon Attempt Restriction

This new server-level feature (meaning that the restrictions set apply to the entire server not just a single site) restricts logon attempts to the FTP server.  This feature will help alleviate brute-force attacks by limiting the number of logon attempts in a specified time period, preventing malicious users or tools from running the gamut of names and passwords to gain access to your server.

When a user reaches the number of failed login attempts, the FTP connection to the client is automatically closed by the server.  The client’s IP address is blocked from accessing the FTP service until the service has been restarted.

In short: FTP Logon Attempt Restrictions can help prevent brute-force attacks on your servers.

IIS CPU Throttling

IIS users have been exclaiming “Finally” since this feature was announced.  CPU throttling allows admins to set the maximum amount of CPU consumption for specific application pools.  When tenants are in a cloud environment, CPU throttling will help prevent a single user’s application from monopolizing CPU resources and slowing down other users.    This resource management also controls resource consumption on a site level, preventing any one site from hogging the CPU’s memory.

In shared-hosting scenarios, where several tenants are on the same server, CPU monitoring will be able to see which users require more CPU resources and potentially prevent low-usage tenants from being over-billed.

In short: With CPU throttling, admins can now monitor usage and set specific levels of CPU usage for different applications.

Improved Live Migration

Hyper-V allows for increased speed of live migrations between clustered virtual servers.  This is, as Microsoft calls it, “live migration without limits.” Now, rather than requiring a shared storage location on the backend, live migration simply copies the memory pages of the migrating virtual machines to the destination prior to migration – with no perceived user downtime.  Plus, admins can use up to 10 gigabytes of bandwidth to complete live migrations.

In Short: Live migration between virtual servers is faster and easier.

Windows Server 8

Easier Security and Compliance

Administrators will now be able to set up centralized access rules and policies by using claims, which are statements about an associated object’s attributes.  These are used to manage access to information, like preventing modification or deletion of files.  With this feature, admins will be able to establish strong, yet malleable rules like “to access files classed as (HBI) data, a user must be a full-time employee, access from a managed device, and logon from a smart card.”

With this, admins will be able to execute an audit on file servers to ensure that employees are in compliance with company and legal policies.

In Short: Administrators can now set up centralized access rules and policies to more easily ensure security and compliance.

Storage Spaces

Storage spaces is a sophisticated storage solution that provides a more cost-efficient and reliable way to store data.  Physical disks will be turned into storage pools that act as storage spaces.  All available physical disks can be used to create one pool, or multiple pools can be created by dividing the physical disks.

Storage spaces are made continuously available by integrating with failover clustering and resiliency modes (mirroring and parity) allow data to be mirrored for backup in the event of storage failures.

In short: Storage spaces are a cost-efficient, reliable, and continuously available storage solution.

Multitenant Security and Isolation

Hyper-V provides the platform capabilities to create private cloud environments and transition to infrastructure as a service (IaaS) environments.  Windows Server 8 has new security and isolation features that use Hyper-V Extensible Switch to make cloud and IaaS environments more secure.  The Extensible Switch is a Layer-2 virtual network switch that provides programmatically managed, policy enforcement on virtual machines that isolate multiple tenants and maintain security.

Interview with Microsoft’s Bob Combs on the Extensible Switch

In short: Hyper-V’s Extensible Switch provides security and isolation for multi-tenant usage.

Other New Features

PowerShell.  Power shell is Microsoft’s command-line shell designed for system admins that has been around since 2006, but Microsoft has pushed to make PowerShell a major component of Windows Server 8 by adding more than 2000 native commands.  We found this nifty PowerShell cheat sheet and a thorough breakdown of all the PowerShell commands in Windows Server 8.

Application Initialization. Allows admins to configure Windows Server 8 to initialize web applications, enabling the application to be ready for the first request.

NUMA-Aware Scalability.  Non-Uniform Memory Access (NUMA) is an architecture that determines memory-based upon memory location relative o the processor.  NUMA prefers local memory access over remote memory access.

WebSocket Protocol.  The new standards-based protocol provides real-time bidirectional communication between a browser or application and a server.  The WebSocket Protocol is supported in IIS ASP.NET 4.5 and WCF for writing server-side applications.

Try it Yourself

Want to test-drive Windows Server 8 for yourself?  Here are some useful documents for getting you started:

• Installing Windows Server 8
• Installing IIS 8 on Windows Server 8
• IIS 8.0 Using ASP.NET 3.5 and ASP.NET 4.5

More New Features…

We’re still digging into the new features.  Follow us on Twitter for more updates as we move closer to the release date, and continue to breakdown the new pieces of Windows Server 8 and IIS 8.

Web Application Security Best Practices for Ecommerce Sites

DevThought rolled out their SPDY indicator exstension for Chrome, which allows you to see when you’re on a site using the SPDY protocol.

Incapsula reported that as much of 51% of site traffic could be non-human with 31% of that being potentially harmful – and you probably don’t even know about it.

BlueCross BlueShield of Tennessee was fined $1.5 million for a data breach in 2009 that saw one million BlueCross members’ information stolen.

Indications that Twitter is using SPDY.  With one of the Internet’s most popular sites on board, who will be next to switch over to the faster protocol?

In the world of information security:

We saw the introduction the Cybersecurity Bill “SECURE IT Act” (Strengthening and Enhancing Cybersecurity by Using Research, Education, Information, and Technology Act) to the Senate, which doesn’t suggest any additional regulations for info security and would distance the government from protecting the private sector.  Others suggest the Department of Homeland Security should be involved.  What do you think the governments role in information security should be?

David Spark writes, “The bad guys are really good at sharing information to break into us. We’re really not that good at sharing information to prevent them from breaking into us.”  Should we be sharing incident data?

Finally, this week showed us a some browser vulnerabilities in  Google Chrome and IE9.  Google offered up cash rewards and credit for finding their bugs.  Microsoft? Not so much.

This past week brought us a few good stories on the importance of site performance.

Walmart did a study to determine how page speed affected conversions and sales.  There were some interesting outcomes here:

How Page Speed Correlates to Business Metrics at Walmart.com

The New York Times published a piece on user’s responses to page speed:

For Impatient Web Users, an Eye Blink Is Just Too Long to Wait

Page load data and tools for  testing your site’s speed:

Making a Fast Website

Stories coming from RSA Conference.

Dwayne Melancon, CTO of Tripwire, suggests companies assess their assets and ask,“What is the value of each asset to my business and how does that change over time? How does it look when things are good, OK, and bad?”

Know Your Assets and How Their Threat Level Changes Over Time

News on the IIS front.

IIS 8

And Scott Forsyth reported new information on IIS 8:

What’s New in IIS 8

The More We Know, The Better We Can Prepare

The landscape of web security is constantly changing with hacking attacks growing more prevalent and diverse.Our job is to constantly be evaluating that ever-changing landscape so we can stay one step ahead and be prepared in the event of an attack.Here are some resources from around the web to keep you informed, prepared, and – most importantly – secure.

2011 Data Breach Investigations Report

2011 represented the all-time lowest amount of compromised data, but also the highest amount of incidents investigated ever.Among the highest hacking methods for 2011 were brute force and dictionary attacks, SQL Injection, and buffer overflow.Web applications were the most attacked pathway when hospitality and retail victims were removed from the data-set, and suffered more numerous attacks than ever.

Read the Report>

Web Application Firewalls can help protect your business from attack. Keeping harmful traffic out and letting good traffic in is crucial to running a business online,just as it is to running a brick-and-mortar business.With attacks evolving and becoming more and more prevalent, a blacklist of signatures is no longer enough to secure web apps.They need protection against threats both known and unknown.

Intrusion Detection FAQ>

Writing an Information Security Policy

An Information Security Policy is the cornerstone of an Information Security Program. It should reflect the organization’s objectives for security and the agreed upon management strategy for securing information.

In order to be useful in providing authority to execute the remainder of the Information Security Program, it must also be formally agreed upon by executive management. This means that, in order to compose an information security policy document, an organization has to have well-defined objectives for security and an agreed-upon management strategy for securing information.

How to Write an Information Security Policy>

Selecting a Web Application Firewall

OWASP, the authority on web security, recommends the following criteria for selecting your Web Application Firewall.

• Protection Against OWASP Top Ten!
• Very Few False Positives (i.e., should NEVER disallow an authorized request)
• Strength of Default (Out of the Box) Defenses
• Power and Ease of Learn Mode
• Types of Vulnerabilities it can prevent.
• Detects disclosure and unauthorized content in outbound reply messages, such as credit-card and Social Security numbers.
• Both Positive and Negative Security model support.
• Simplified and Intuitive User Interface.
• Cluster mode support.
• High Performance (milliseconds latency).
• Complete Alerting, Forensics, Reporting capabilities.
• Web Services\XML support.
• Brute Force protection.
• Ability to Active (block and log), Passive (log only) and bypass the web trafic.
• Ability to keep individual users constrained to exactly what they have seen in the current session
• Ability to be configured to prevent ANY specific problem (i.e., Emergency Patches)

Ten Ways to Avoid Costly PCI Compliance Violations

The first tip for avoiding costly PCI Compliance violations (in the above piece) is familiarization with the requirements themselves.  With the complexity and severity of security breaches always growing, it is crucial to know and understand the security standards required to store, transmit or process payment cardholder data.  While the 75 page PCI DSS “Requirements and Security Assessment Procedures” document may be somewhat daunting in its requests and exhaustive calls for  implementation, it can be simplified to:

• Build and Maintain a Secure Network
• Protect Cardholder Data
• Maintain a Vulnerability Management Program
• Implement Strong Access Control Measures
• Regularly Monitor and Test Networks
• Maintain an Information Security Policy

When you break down these main categories, there are 12 provisions to achieve PCI DSS compliance.   Not only are these requisite provisions for PCI Compliance, but they are a great template for security for any type of business.

Getting Started with the PCI Data Security Standard>>>

A while back we posted the following PCI quick tips, which are still applicable:

Do:

• Encrypt cardholder data.
• Use products that are approved for the PCI standard.
• Understand the concept of compensating controls.
• Organize PCI compliance as an on-going, cross-functional project–not as a one-time event.
• Understand your cardholder information business process from end to end.
• Take the time to read and understand the PCI Data Security Standard.

Don’t:

• Store unnecessary cardholder data beyond receiving the authorization code.
• Be lulled into thinking that you would not be a target for criminals.
• Try to create your own crypto solutions.
• Assume your vendor is protecting you.

Through all the preparation and planning, let’s not forget that PCI DSS does not make a company immune from attack.  It can and does still happen – after all, a determined hacker can bypass any security.  This is why PCI DSS Compliance, and security as a whole, must be treated as an ongoing processes with a time investment in-line with how much your company values staying in business.