The Barking Seal

Q1 2010 Printed Barking Seal Newsletter Hot off the Presses

16Mar

Author: beth Categories: Ramblings Comments: 0

Did you know that in addition to the Barking Seal blog, Applied Trust also has a quarterly print newsletter called The Barking Seal that features entirely different content? If not, now is the time to check it out! The printed Barking Seal first debuted in 2005, with the goal of providing a trusted source of useful information about the IT security and infrastructure arena to our clients, supporters, and friends. Since then we’ve covered many hot topics in the industry, and our latest issue is no exception. The Q1 2010 issue includes a feature article about the importance of change management, as well as a secondary article about our recent awarding of QSA certification status by the PCI DSS. You can read the issue online here, and if you’d like to subscribe to the printed edition, you can sign up here. Happy reading!

Tags: applied trust, newsletter, Security

Enlightening the Confused Deputy

09Mar

Author: zack Categories: Infrastructure, Security Comments: 0

Confused Deputy
One of the most interesting (in other words, “dangerous”) vulnerabilities that almost every existing web application falls victim to is cross-site request forgery (CSRF – “sea-surf”). CSRF is a type of malicious attack vector whereby unauthorized commands are transmitted from a user that the website trusts. It is an example of the confused deputy problem. This is different than the widely-known cross-site scripting (XSS) in that CSRF exploits the trust that a site has in the user’s browser, and XSS exploits the trust a user has for a particular web site.

PCI-DSS Compensating Controls

25Feb

Author: randy Categories: Security Comments: 0

Applied Trust recently achieved Payment Card Industry (PCI) Qualified Security Assesssor (QSA) status. Most companies that pursue this credential do so solely for the purpose of being able to perform QSA-certified audits as defined by the PCI standards council. The PCI standard requires that an organization is 100% compliant across all requirements. For requirements that cannot be exactly met, PCI allows the use of compensating controls. For a variety of reasons, we think that this area is an important aspect of our PCI compliance practice.

When real-world conditions present challenges to compliance with the PCI standard as written, we work with our clients to identify, document, and evaluate appropriate alternatives. These compensating controls are not a get out of jail free card – there are specific rules as to when and how they may be applied. Specifically:

Compensating controls may be considered for most PCI DSS requirements when an entity cannot meet a requirement explicitly as stated, due to legitimate technical or documented business constraints, but has sufficiently mitigated the risk associated with the requirement through implementation of other, or compensating, controls.

Compensating controls must satisfy the following criteria:

Read more »

Tags: compliance, Security

PCI DSS-driven assessment

15Feb

Author: ned Categories: IT Management, Security Comments: 0

The PCI DSS (Payment Card Industry Data Security Standard) sets a number of expectations for IT assessment. Activities, from scanning for rogue wireless access points to reviewing vendor contracts, are scattered throughout the PCI Data Security Standard document.

Below is an attempt to assemble those requirements into a single schedule. Where the standard didn’t specify a frequency, I used reasonable “best practices” values. I hope this is a useful starting place for organizations working toward compliance, but it is definitely not a holistic IT security plan! There are lots of other security activities that should be taking place at every organization – this is just a summary of those discussed in the PCI DSS.

See anything that I missed? Did I get something wrong? Let me know in the comments and we’ll work toward an accurate sample schedule together!!

HITECH business associate deadlines looming

10Feb

Author: ben Categories: IT Management, Security Comments: 0

We wrote about the HITECH act and its impact on business associates a little less than a year ago. By February 18, business associates are required to:

Comply with the HIPAA security and privacy rules
Provide medical information breach notifications
Work with the Department of Health and Human Services to perform compliance audits as requested
Train employees on HIPAA and its requirements for business associates

BAs, I hope you’re taking note. Violations can incur fines for as much as $1.5 million per year and, in the most serious circumstances, may include prison time. According to HITECH, DHHS audits are also mandatory beginning 2/18/2010. (See sections 13410 and 13411).

Most of the associates that I’m familiar with haven’t made many changes in the past year to improve HIPAA compliance. So what should any self-respecting business associate, now subject to these somewhat draconian and certainly expensive rules, do to avert heavy fines and lost productivity? Avoid becoming a business associate at all costs.

First, re-evaluate whether the business truly qualifies as an associate, for one. In the past, BAAs had very few directly applicable requirements, and those that were in place were rarely or never audited and enforced. Businesses should no longer haphazardly sign BAAs when they aren’t strictly necessary.

If the business has determined that they are indeed an associate, what can be changed to eliminate that status? If there isn’t a dire business need for access to medical records, but they’re being collected incidentally, eliminate that dependency and escape the compliance game. Of course, most health care organizations don’t freely distribute health records, and most organizations don’t want them unless they need them.

If the business is resigned to being an associate subject to HIPAA courtesy of HITECH, it’s time to get to work. Start at www.hipaasurvivalguide.com, an excellent resource for learning the regulation and applying its teachings.

And never forget the old proverb (that I’m making up right now): more regulation always improves security. Emphasis added.

Tags: Compliance series, HIPAA, regulations, Security

2009 CSI Computer Crime and Security Survey Says …

11Dec

Author: beth Categories: Security Comments: 0

Daisy is one of the attackers identified by the CSI

Daisy, an attacker identified by the CSI

The Computer Security Institute has just released the results of its 14^th annual Computer Crime and Security Survey and, as always, there are some interesting findings. This year’s results are based on 443 responses given by information security and information technology professionals in U.S. corporations, government agencies, financial institutions, educational institutions, medical institutions, and other organizations, from the period of July 2008 to June 2009.

A few highlights:

Average losses resulting from security incidents dropped from $289,000 per respondent last year to $234,244 per respondent this year.
A third of respondent organizations reported being fraudulently represented as the sender of a phishing message.
Respondents reported big jumps in the incidence of financial fraud, malware infection, denials of service, password sniffing, and Web site defacement, and significant dips in wireless exploits and instant messaging abuse.
Financial fraud losses averaged $450,000 per organization that suffered fraud.
A quarter of respondents believed that more than 60% of their financial losses resulted from non-malicious actions by insiders.
The largest increases in security technologies used were in anti-spyware software and tools that encrypt data at rest.
Tools that improve visibility, such as log management tools and security information and event management tools, were high on many organizations’ security wishlists.
Only 7.7 percent of respondents categorized their organizations as being in the “health services” industry, but 57.1 percent of respondents said their organization had to comply with the Health Insurance Portability and Accountability Act (HIPAA). More respondents said that HIPAA applied to their organization than any other law or industry regulation.
Respondents generally reported that regulatory compliance efforts have had a positive effect on their organization’s security programs.

For more specifics, check out the free Executive Summary of the Survey that’s available from CSI’s web site. CSI members get a copy of the comprehensive version, and it will be made available to non-members for a fee at some point.

Tags: csi, Security

Compliance Series: PCI Data Security Standard

28May

Author: ben Categories: IT Management, Security Comments: 1

I’ll kick off my much-delayed series on compliance and regulation with the Payment Card Industry’s Data Security Standard. This highly visible, widely applicable standard applies to any company that processes credit card data. Importantly, the standard was developed by the industry rather than congress. This is in direct contrast to many other industries (such as health care and finance) that are regulated by the federal government.

The standard consists of 12 requirements, each with a number of sub-requirements, ranging from firewall configuration to security policy to ongoing vigilance. There are four tiers of merchants, and slightly different requirements apply depending on the tier. Read on for details and tips.

Blackberry Security: Risking the Whole Enterprise

30Apr

Author: trent Categories: Security Comments: 0

I was speaking with a respected colleague today about the security of Blackberries vs. other mobile devices. The conventional wisdom of the business community, apparently, is that the Blackberry is some form of superhero-grade magical device, impervious to all forms of cybersecurity attack, and hence suitable for handling all levels of sensitive communication (and soon suitable for President Obama).

It’s true that RIM (Research in Motion), Blackberry’s maker, has an excellent marketing department (and, as excellent marketing departments are hard to come by, I at least give them kudos for that). They have spun a fantastic tale about how, by simply installing their superduper-secure Blackberry Enterprise Server (BES) product, you have created a secure channel between the enterprise network and a user’s eyes/ears. As far wireless communications channels go, they have an “ok” solution for securing transport to the Blackberry device itself. The highest security risk of using a Blackberry is NOT that your data is compromised while being transmitted wirelessly. Instead, there really are two high risk scenarios when using a Blackberry in an enterprise:

Walk, then run – thoughts about event value

11Oct

Author: trent Categories: Ramblings, Security Comments: 0

In his post On the difficulties of event correlation, Ben talks about how hard event correlation is – and I couldn’t agree with him more. In addition, I am often surprised about how many organizations blindly run down the path to adding more event collection to their environment before they understand the ones they already have.

A great example is IDS deployment. Along with the rest of the infosec establishment, I generally agree that enterprise-wide IDS can be an important part of a comprehensive infosec program. However, I often see that such deployments don’t succeed in the long run. Everyone is excited about it initially, but after a few months their interest wanes and the platform falls into a state of disrepair. Why? Is it because IDS data isn’t useful? Not at all. Instead, I think these are the drivers:

Poor event correlation. Ben makes some suggestions as to why, but the bottom line is that it’s really hard to use data that isn’t correlated with the rest of the environment.
Failure to budget staff resources to maintain the platform — there is an additive staff cost of deploying IDS, even if 7×24 monitoring is outsourced.
IDS events are not on the top of the list of “event value.” By “event value,” I mean that eventually, folks realize that there are more important events that they’re not capturing. Events like “server down,” “disk full,” or “network linked failed.” If they’re not reporting/handling these higher value events already, adding a high quantity of lower value events results in them being perceived as noise.

This last item is really important and apparently not obvious. The bottom line is this: before deploying a platform like an IDS, first make sure that you’re already capturing and managing the interesting, high-value events that currently exist in the environment. OS and infrastructure device logs are already easily available, take time to capture them centrally and use them. One that’s been mastered, then it’s reasonable to take on the IDS event stream.

Tags: rants, Security

Categories

Archives

Recent Posts

Recent Comments