SecureWorks - On the Radar Newsletter - MAY 2009
Tips for Staying Secure in a Down Economy Monitoring AS/400 Audit Logs Security 101: Web Application Firewall SecureFacts

Tips for Staying Secure in a Down Economy

With the economic downturn continuing, industry analysts have predicted a significant slowdown in IT spending growth in 2009. According to Gartner, Inc., worldwide IT spending is expected to decline 3.8 percent in 2009¹. While IDC's prediction of 2.6 percent year over year growth² is slightly more optimistic, it is still a significant reduction compared to prior expectations. Organizations are tightening their budgets across the board and taking a hard look at all projects and initiatives to find places to reduce costs. This means they must do more with less to protect their assets from today's threats.

Unfortunately, attackers do not care if you have fewer resources available to protect your business. There will be no slowdown in the volume or the sophistication of cyber threats. Threats will continue to increase and evolve, perhaps even more so as individuals caught by the economic downturn turn to illegitimate means such as identity theft, fraud and cybercrime to make more money.

Likewise, regulators will also continue to put pressure on IT security to comply with standards and guidelines, regardless of economic conditions and your budget situation. And as threats evolve, so must your controls to ensure compliance with the intent of industry regulations and standards such as PCI, GLBA, FISMA, HIPAA, etc.

The combination of more security and compliance needs and fewer resources to satisfy those needs makes it very tempting to cut corners to make ends meet. But cutting corners only increases the risk to your organization over the long term. Instead, consider the following tips to help you make the most of your budget and stay secure: 

Tip: Work smarter, not harder

Before you spend resources on a new project or technology, evaluate your existing security controls and functions to be sure you're making the most of the capabilities already available to you. Many systems have native security capabilities that are under-utilized or not used at all that would improve your security posture. And often newer versions or updates include new features or technologies that can address new issues you face. Understanding what those capabilities are may save you the cost of buying, deploying and learning another technology to address a particular security or compliance need.

Organizations should also seek to offload highly-repetitive or "operationalized" tasks that consume significant resources to manage over time. Tasks such as security device tuning, log auditing and event correlation and analysis are security functions that can be performed by less expensive sources such as a Managed Security Services Provider or your own IT operations group. Offloading these tasks also allows you to shift more expensive security resources to strategic projects where their expertise is most effective.

Tip: Tie security to business initiatives

Now more than ever, it is very important to make security relevant to business initiatives. Secure funding by getting involved early in the process so that security costs are included in the business case for new initiatives. Work with business leaders within your organization to support security for their areas of responsibility, but don't rely solely on regulatory compliance as your justification. Make the effort to show how and where security fits into a business process, and what the risks are to that process without adequate security controls in place. Having a solid security governance and risk management framework in place makes this easier because it aligns policies, procedures and standards with overall business needs. 

Tip: Security first, then compliance

Regulations are a necessary burden, but far too often compliance-driven projects are shortsighted and focused on satisfying minimum requirements (e.g. the "checkbox" approach) instead of reducing risk and addressing the intent of the regulation. While cheaper in the short term, this approach leads to "panic spending" and higher costs in the long run.

This approach can also lead to the kind of devastating breach that has occurred at TJX Corporation and Heartland Payment Systems. Both organizations believed they had preformed to the letter with regard to compliance. When a breach occurred, it was little comfort to them to find that the regulation was found wanting. The damage was done, costing them millions of dollars in expenses and lost business. And to add insult to injury, they were also fined by their regulators.

If your organization is subject to multiple regulations, it also pays to recognize requirement overlap between regulations. In many cases, compliance costs can be consolidated by taking advantage of overlaps. When addressing compliance requirements, consider more comprehensive "best practice" options that can be extended beyond narrow regulatory requirements.

Tip: Be a savvy buyer

Price is important, but make sure you compare apples to apples when evaluating proposals. Keep in mind that cut-rate alternatives are cut-rate for a reason and will likely cost you more in time and wasted resources. The vendor community has also been affected by the recession, so it is also important to evaluate a vendor's financial health. This is particularly true if you intend to have an ongoing relationship with the vendor.

For the vendors you work with, it also pays to understand what other products or services they offer and what kind of upgrades are available. In some cases, the vendor may be able to satisfy other needs you have at a lower overall cost. Additionally, look for product/service bundles that fill security and compliance requirements at a lower total cost of ownership.

For more tips and advice, view the archive of our May 5^th webcast: Staying Secure in a Down Economy.

1. http://www.gartner.com/it/page.jsp?id=925314
2. http://www.idc.com/getdoc.jsp?containerId=prUS21517508

Monitoring AS/400 Audit Logs

Midrange platforms such as the IBM System i (also commonly referred to as iSeries or AS/400) support key business processes and applications for a wide range of organizations. Because of this, businesses must take steps to manage risk to these systems and maintain their integrity and availability. Additionally, auditors and regulators are paying increasing attention to the controls organizations have in place to safeguard these critical IT assets.

The System i platform has always been a platform where the operating system and features are developed with a focus on security and as such have always enjoyed a reputation as one of the most secure systems available. However, the increasing sophistication of attacks on critical business infrastructure demands vigilant security monitoring of midrange platforms.

The System i operating system, i5/OS, features detailed audit logging using a function called the Security Audit Journal. Properly configured, the Security Audit Journal creates audit entries documenting the events that take place on the system. The Security Audit Journal allows for granular customization of auditing parameters. Administrators should take a pragmatic risk-based approach to establish sufficient audit logging without compromising system capacity and performance.

To effectively analyze System i events, you must understand what the Security Audit Journal log entries actually represent. Understanding the System i log entries allows you to understand the activity being logged so that it can be interpreted correctly and put into the appropriate context for correlation and analysis. Having context is important because it helps to identify relevant relationships between events that may be indicative of malicious activity or policy violations.

There are 74 distinct kinds of security-related events logged by the Security Audit Journal to document events including but not limited to:

• Access to objects, files and tables
• Login attempts
• Modification of objects and user privileges
• System configuration changes
• Other security and audit events

Each kind of event can contain up to 44 substitution variables which are populated by meaningful data in the log entry. An example of a log entry is below, with substitution variables denoted by "&n" where "n" is a number between 1 and 44.

Supporting key business processes, System i platforms are typically heavily utilized which means they can easily generate large volumes of audit logs on a daily basis. Combined with the potential diversity of Security Audit Journal entries, the volume of log data makes manual analysis an impossible task to perform in time to mitigate threats and protect your assets. Technology is needed to automate correlation and analysis to identify relevant security events that need investigation.

However, System i platforms do not natively support forwarding audit logs to external log monitoring and Security Information Management (SIM) tools. To overcome this, agent software can be deployed on the midrange platforms to capture audit entries and forward them to the log monitoring technology. Once there, events can be processed, archived and reported for assessment and response and to support audit requirements.

For example, the SecureWorks i5/OS agent used to support our AS/400 monitoring service collects security-relevant events from AS/400, System i and iSeries platforms and transmits the events to the Sherlock Security Management Platform. At this point, the System i security events are filtered, consolidated and correlated with events from other data sources such as:

• Firewall logs
• Intrusion detection and prevention systems
• Network devices (routers, switches, etc.)
• Host logs (operating systems, databases, applications)
• Vulnerability scans
• Threat intelligence from our Counter Threat Unit^SM

Using advanced logic engine technology to perform real-time analysis across these data points, Sherlock identifies actionable information and presents it to our certified experts for assessment and response. Events are recorded in the SecureWorks Portal, providing documentation to demonstrate to auditors that the appropriate monitoring controls are in place to protect midrange systems and the data they process, transmit and store.

To learn more about log monitoring for System i, iSeries or AS/400 platforms, visit our Security Monitoring for AS/400 Systems webpage or request more info.

Security 101: Web Application Firewall

Web applications are a prime vector of attack for hackers and cybercriminals. To attack Web applications, hackers take advantage of attack vectors that bypass traditional network and host-based security technologies such as firewalls, intrusion detection and prevention systems (IDS/IPS), and unified threat management (UTM) devices. With greater visibility into application-layer traffic, Web Application Firewalls (WAFs) provide protection against these threats.

What is a Web Application Firewall?

A Web Application Firewall is a security appliance that inspects Web (HTTP and HTTPS) traffic and applies rules to detect attacks and policy violations. A WAF appliance is typically deployed in-line in front of one or more applications so that web application attacks can be blocked before they reach their target. Capable of inspecting Web application traffic, Web Application Firewalls can detect and block Web application attacks such as SQL injection, cross-site scripting, session hijacking and Web 2.0 attacks. 

Why are Web Application Firewalls needed?

WAFs are needed to protect organizations from attacks that exploit vulnerabilities in web applications used to support website features such as internet banking, online shopping carts, login pages, forms and dynamically-generated content such as user ratings, forums, etc. Traditional network and host-based security technologies do not provide adequate protection against these attacks because they cannot provide the level of application-layer traffic inspection needed to accurately differentiate between legitimate user interaction with web applications and attempts to exploit a web application flaw.

Regulatory bodies have also recognized the threat posed by web application attacks and require organizations to take adequate measures to secure their web applications. For example, the Payment Card Industry Data Security Standard (PCI DSS) mandates that merchants and service providers protect public-facing web applications against known attacks. This can be accomplished by using a WAF to prevent attacks and/or addressing web application vulnerabilities by performing scans or source code review. 

How does a Web Application Firewall work?

A WAF inspects all inbound and outbound application traffic (HTTP) including encrypted traffic (HTTPS), applying policies or rule-sets to determine if traffic is malicious or inappropriate. Based on that determination, the WAF will take one of the following actions:

• Pass the application traffic
• Generate an alert and pass the application traffic
• Generate an alert and block the application traffic

Which action is taken depends on the configuration of WAF policies and rule-sets. Capable of "learning" application logic, WAF technology is designed to profile application behavior over time to allow for accurate threat detection. However, without ongoing tuning WAFs can block legitimate application traffic (a.k.a. false positives) and pass traffic containing threats (a.k.a. false negatives). As Web applications change, so must WAF policies to ensure accurate protection. Proper tuning of WAF policies requires strong security and Web application expertise, as well as the time to analyze traffic and test policies and rules before deploying them. For organizations that rely on dynamic Web applications that are frequently modified, managing WAF performance can be a significant challenge.

For more information about Web Application Firewalls and SecureWorks' services, visit our Managed Web Application Firewall webpage.

SecureFacts:

$10 Million

Ransom payment demanded by hackers for the release of patient records belonging to Virginia's Prescription Monitoring Program