On Wednesday, the Federal Trade Commission announced they were delaying enforcement of the ID Theft Red Flags Rule until May 1, 2009. This delay ONLY applies to organizations supervised by the FTC. It does NOT apply to institutions supervised by the member agencies of the FFIEC (FDIC, OTS, OCC, FRB and NCUA). As of this blog posting, there has been no public announcement from the FFIEC agencies regarding any extension of the November 1 compliance deadline for Red Flags.

According to the press release, the deadline is being moved further out because of a uncertainty about who has to comply with the Red Flags Rule:

“During the course of these efforts, Commission staff learned that some industries and entities within the FTC’s jurisdiction were uncertain about their coverage under the Rule. These entities indicated that they were not aware that they were engaged in activities that would cause them to fall under the FACT Act’s definition of creditor or financial institution. Many entities also noted that, because they generally are not required to comply with FTC rules in other contexts, they had not followed or even been aware of the rulemaking, and therefore learned of the Rule’s requirements too late to be able to come into compliance by November 1, 2008. The Commission’s delay of enforcement will enable these entities sufficient time to establish and implement appropriate identity theft prevention programs, in compliance with the Rule.”

We’ll keep an eye on this and provide an update if we hear anything from the FFIEC agencies.

A weekly feature highlighting news stories, reports and editorials of interest to IT and security managers. Also see stories including SecureWorks news, press releases, and research.

CNET: Adobe addresses Flash Player ‘clickjacking’ flaw

CNET: Report: As stock market drops malware rises

SC Magazine: FTC extends “Red Flags Rules” enforcement six months

Dark Reading: ‘Block the Vote’ Tactics Go Online This Election

Network World: P2P legislation forcing university IT to get tough on piracy

To follow up on a question that was asked during our recent webcast “PCI DSS v1.2: What You Need to Know“, here are links to the various card brands’ compliance programs where you can find detailed information on their requirements for protecting cardholder data:

• American Express: www.americanexpress.com/datasecurity
• Discover: www.discovernetwork.com/fraudsecurity/disc.html
• JCB International: www.jcb-global.com/english/pci/index.html
• MasterCard: www.mastercard.com/sdp
• Visa: www.visa.com/cisp

These, in addition to the PCI Security Standards Council’s website, are good resources for learning more about what it takes for your organization to be compliant.

There are hundreds of security certifications out there, but not all are equal when it comes to validating a person’s security expertise. Like security ROI, compliance v. security, etc., this is a topic that seems to raise its head every so often in the security community. Last week, Stephen Northcutt (President of SANS and founder of the GIAC certification) gave his take:

“First, what does a security certification prove? Security certifications prove that the candidate meets a minimum standard. How do you know what a certification is worth? By making sure you understand what the minimum standard is and what the quality of a certification is.

Let’s do the quality part first. Anybody and his brother can go out and write some questions and pretend to offer a certification. But, when they do that, there is no quality review, and that gives people like the original blogger an understandably bad taste in their mouth. So, the first step is to find out if the certification provider has undergone, or is undergoing IS0 17024 certification for certifications. That doesn’t prove their content is perfect, but it goes a long way towards assuring their process is repeatable and solid.

Now, let’s address the “minimum standard” part of a security certification. Quality and respected Security Certification providers like (ISC)2, ISACA and GIAC, develop a Job Task Analysis for their certifications. Here is a nice discussion of a Job Task Analysis (JTA) that has nothing to do with Security. Each and every certification should have a JTA describing the knowledge, skills and abilities required for that particular job. The more detailed and fine-tuned the JTA, the easier it is to address the minimum standard assured by the certification. For instance, the CISSP is so broad you can really only say it proves you know the basic theory and terminology of security. The CompTIA Security+ is similar; it says you know enough theory and terminology of security to be entry level. The GIAC GSEC is pretty much in the same boat; it says you know essentially the same theory and terminology of security as the CISSP, but you also know some pragmatics (what tools to use and when, operating system basics, some hands-on experience). In all three cases the minimum standard is a broad understanding of security; none of these certs demonstrate deep knowledge, but all of them assure employers you have the foundation to understand security. This may sound trite at first, but all three also demonstrate that you can read, write, reason and memorize, which are, in fact, important skills.

In order to go beyond “memorizing mostly useless and dated facts”, the JTA has to get more specific. If I was an employer looking for a quality measurement tool for potential candidates, I would look for a security certification that has quality and is specific to the job I am trying to fill. For instance, SecureWorks, probably the best IDS/Log Monitoring Outsourcing contractor in the industry, requires Intrusion Detection certifications. Currently they require the GCIA, but I am sure that they would accept a resume from anyone with a quality certification in the same field.”

Stephen is right. If you’re evaluating job candidates you have to understand what holding a certification really means for a person’s expertise and ability. Here at SecureWorks, we gained that understanding through first-hand experience with the multitude of available certs. This experience led us to requiring the GCIA for all SOC analysts because it aligns very well with the baseline level of technical expertise and proficiency we need from our analysts to provide the best quality of service.

If you don’t have first-hand experience, I suggest taking Stephen’s advice: research the verifiable steps a certification provider has taken to ensure the quality of their certifications (e.g. ISO 17024) and how the specific certification applies to the job to be done (e.g. JTA).

Network World recently published survey results from Infonetics Research on the use of Network Intrusion Prevention System (NIPS) products from TippingPoint, Cisco, IBM (ISS), McAfee and Sourcefire. The survey, sponsored by TippingPoint, found that a large portion of IPS devices deployed in corporate environments (average company size surveyed was 9,418 employees) are either (A) not deployed in-line where they can block attacks or (B) deployed in-line but without blocking filters fully enabled.

This is along the lines of what we’ve seen as a Managed Security Services Provider. More often than not, prior to working with us organizations are still not using many of the blocking capabilities that make Intrusion Prevention Systems a significant step up from Intrusion Detection Systems. Even in cases where the appliance is deployed in-line, it’s very rare to see more than 75% of its signatures configured to block malicious traffic because organizations just don’t want to take the risk of blocking legitimate traffic. It’s a confidence problem - one that’s bred from experiencing high rates of false positives in both IDS and IPS products.

Our solution to that problem has been a services model for IPS, through our iSensor IPS appliance and Managed IPS services. Why? Because maximizing IPS blocking capabilities while minimizing false positives requires an in-depth understanding of your network traffic, the IPS technology deployed and the threat environment. You also need the resources and expertise to apply that understanding to managing your IPS performance in an ongoing basis. Most organizations can’t do all of that cost effectively, which is why SecureWorks’ services continue to be a very attractive path for organizations that want to get the most value out of IPS.

The long anticipated version 1.2 update to the PCI Data Security Standard was released Wednesday by the PCI Security Standards Council, following the big PCI North America Community Meeting down in Florida last week. As a Qualified Security Assessor (QSA) and Authorized Scanning Vendor (ASV) for PCI, we’ve been paying close attention to what’s been going on and we sent several representatives to last week’s community meeting.

We’ll be holding a free webcast on PCI DSS v1.2 on October 14. If you’re concerned at all about what sort of impact the new version is likely to have on your organization, I recommend dropping in. We try to keep our webcasts short and sweet, so this one will likely take 30 minutes or so. We will also do a live Q&A during the webcast to help answer questions attendees have about version 1.2. For anyone that can’t make it on October 14, we’ll be posting the archive a couple of days later here on the website.

As a side note, we also published the latest installment of our monthly “On the Radar” newsletter yesterday. It has some good stuff inside, including a year-to-date Regulatory Roundup for IT Security, research from our Counter Threat Unit on which countries most attacks are coming from, and also a best practices article on Security Awareness Training. Check it out.

If you have not checked out www.pcisecuritystandards.org since they updated their site, I’d urge you head over there. The redesign makes it much easier to find and access information on the PCI DSS – including summaries, explanations and easy to find links to the full documentation. This makes PCI the gold standard for explaining regs – I wish the Federal regulatory bodies would do this for GLBA, HIPAA, etc. This screen shot shows a lot of the new features and improved search capabilities:

If you care about PCI, it’s worth a visit.

According to news reports, an unencrypted laptop containing personal identification information for 33,000 registrants for the “Clear” program was stolen recently from an office at San Francisco International Airport. For those unfamiliar with “Clear”, it is used by several major airports to allow pre-screened flyers to bypass regular security lines. Their customers pay an annual membership fee to be a part of the program and go through a more in-depth screening process that involves submitting to a background check and threat assessment as well as providing biometric data in the form of finger prints and iris scans. As usual, the Breach Blog has a good summary of what’s known so far about the breach.

From The Orlando Sentinel:

“The Transportation Security Administration said it has instructed all airports that contract with Verified Identity Pass Inc. — which operates the “Clear” program at OIA and nearly 20 other airports across the country — to suspend enrollment in the service and to secure all unencrypted computers until encryption software is installed. The agency also instructed San Francisco International Airport, where the laptop was lost, to ensure that Verified Identity Pass immediately contacts everyone whose personal information was stored on the missing computer.”

Verified Identity Pass claims the stolen laptop contained less sensitive information like driver’s license numbers and passport numbers but not any credit-card numbers, social security numbers or biometric information. That’s good, but it doesn’t shake the fact that the stolen laptop was unencrypted in the first place.

For the service they provide, it’s hard to believe the company didn’t consider laptop theft to be a serious enough business risk to warrant the cost of encryption. Even though the compromised information wasn’t as sensitive as it could have been, they’re still losing revenue from new enrollees (at least temporarily) and they’re most likely going to have to deal with increased scrutiny from the TSA. Trust wasn’t broken, but it was surely weakened.

What if it they weren’t as lucky and there happened to be biometric data or social security numbers on the stolen laptop? You shouldn’t base your security efforts on improbable “what ifs”, but can anyone honestly say this is improbable anymore with all the breach notices and stolen laptops reported in the last few years?

Update: Seems Rothman ran into this in ATL on his way to Vegas for Blackhat.

Update 2: Turns out the missing laptop was found. In the same office. Just in a different spot. Either someone jumped the gun on declaring the laptop missing or whoever took it was able to sneak it back into the locked office without anyone noticing. Perhaps it’s a really tiny and inconspicuous laptop? Maybe a MacBook Air? Wouldn’t be the first time one of these has caused problems with airport security… /snark

Thanks again to everyone who attended our recent “Red Flags Update” webcast. By popular demand, slides from the website can be downloaded here (PDF). Also, an archive of the webcast will be available on-demand in our Webcast Archives. If you have any comments or suggestions for future webcasts, feel free to send them to info at secureworks dot com. Your feedback is most appreciated!

In a CLM of epic proportions (and with possible legal consequences), a network administrator for the City of San Francisco cut off access for some of the “higher ups” in the city’s Department of Technology. Courtesy of SFGate:

“A disgruntled city computer engineer has virtually commandeered San Francisco’s new multimillion-dollar computer network, altering it to deny access to top administrators even as he sits in jail on $5 million bail, authorities said Monday.”

“Childs created a password that granted him exclusive access to the system, authorities said. He initially gave pass codes to police, but they didn’t work. When pressed, Childs refused to divulge the real code even when threatened with arrest, they said.”

The result? A big headache for the city, which now has to crack Childs’ pass code – effectively breaking in to their own system – to regain access.

Further down in the article we find that the accused administrator was already on the hot seat:

“Childs has worked for the city for about five years. One official with knowledge of the case said he had been disciplined on the job in recent months for poor performance and that his supervisors had tried to fire him.”

To state the obvious, insiders with privileged access can do a great deal of damage if their activities go unchecked. Adhering to the principle of least privilege is ideal, but it can only go so far to reduce the risk of insider abuse especially when it comes to locking down administrative access for some network and IT systems. That’s why it’s always good practice to have other controls in place, such as reviewing access privileges before or immediately after potentially volatile events (like disciplinary measures or terminations) and monitoring root and administrative activity on critical systems. It’s also a good idea to have a qualified 3rd party periodically audit your access controls to determine if they sufficiently minimize the risk of insider abuse.