Red Flag Rules - The New Deadline

For the people that are not privy to the next deadline, there is one coming up this week. On November 1st, there are three rules that are coming into play from the federal government - like we didn't have enough already to deal with!

Let me give a little background to this first.

The Fair and Accurate Credit Transactions Act (FACT Act or FACTA) was passed back in 2003 to try and get a better handle on identity theft - both on the monitoring and potential prevention on the matter. The FACT Act amended the previous passed Fair Credit Reporting Act (FCRA) that was passed way back in the 1970s. To put a little context to it, FACTA is the law that allows people to get a free credit report once a year from the credit trio (Equifax, Experian, and TransUnion).

One of the sections that were included within the FACT Act was three requirements for businesses to comply with regarding protecting identity theft. These are better known as the Red Flag Rules.

The Rules

The Red Flag Rules have three primary sections to it but I'm going to be focusing on the first and broadest applicable area: implementing an Identity Theft Prevention Program.

As part of the new regulation, companies are now obligated to develop and maintain a Identity Theft Prevention Program. Well what does that mean actually? According to the FTC, they have to include "reasonable policies and procedures for detecting, preventing, and mitigating identity theft". Additionally you need to make sure they enable companies to:

1. Identify relevant patterns, practices, and specific forms of activity that are “red flags” signaling possible identity theft and incorporate those red flags into the Program;
2. Detect red flags that have been incorporated into the Program;
3. Respond appropriately to any red flags that are detected to prevent and mitigate identity theft; and
4. Ensure the Program is updated periodically to reflect changes in risks from identity theft.

Who needs to be compliant?

Since this is a law, the applicable entities are wide spread. As defined by the law, this applies to all businesses that have "covered accounts". Covered accounts are any accounts that include foreseeable risk of identity risk. This could include credit cards, monthly-billed account like utility bills, cell phone bills, social security numbers, drivers’ license numbers, medical insurance accounts, and possibly others. Obvious that it would be a shorter list to come up with the businesses that are not affected by these rules.

How do you become compliant?

Well that's the magic question!

As of right now, there is nothing of a measurement to what is sufficiently compliant and what is not. Of course since this is a regulatory law, the actual controls dictated are very general in nature; giving broad programs that needs to be in place within the organization.

The best advice to accomplishing this is to follow general security guidelines. Some important components to include are: policies and standards, incident response program, security incident and event monitoring (SIEM), and strong logical controls within your environment. Following frameworks and guidelines, like with the ISO 27001 or NIST 800-53, can give you guidance in developing the programs and controls as well.

So who's to enforce the law?

Since this is a federal business law, this primarily falls under the Federal Trade Commission (FTC) - though there are provisions that the National Credit Union Administration (NCUA) and Federal backing agencies can also enforce this. Does this mean that they are going to be performing audits against companies - unlikely, but that doesn't mean they will not investigate organization based upon reported incidents. In the infamous case of TJX, once the information from the breach was made public the FTC came in and actually mandated controls be put in place. This includes audits on a bi-annual basis and maintaining a "comprehensive information security program".

In the end, this just strengthens the need for organizations to develop an Enterprise Security Programs (ESA) within organizations. Even though this is yet another law, bringing with them the generic mandates to companies, performing best practices and continually assessing and improving your security program will be more than enough to include these added rules.

Read more!

Building an Information Security Program, Step One

Put firewalls everywhere!

No.

Build an Incident Response Program!

Wrong.

Write Minimum Security Baselines!

I would disagree.

Classify your data?

Ding, ding, ding...we have a winner. If you guessed option four, please move to the head of the class.

When establishing a strong information security program, your primary focus is on securing data. The first step in securing data in an organization, is to know and document what data you store, transmit and receive. After going through the process of identifying the data, the next step is to classify it.

What data is public?

What data, if lost, would cause corporate heartburn? Would the loss contribute to outside competitive advantage?

What data, if lost, would be catastrophic to daily business, and potentially cost the organization millions of dollars in recovery fees, fines, and lawsuits?

There are numerous, high-level processes to use for classifying data. Most organizations can quickly tell you in five minutes what their most critical data is. But do they know exactly where that data flows within the business, as well as externally? Usually not.

Only with data classification can you perform asset classification. If a host stores sensitive data, it's criticality to the organization is raised. You then build further security controls around this sensitive host.

Only with data classfication can you build an information incident response program. How do you effectively respond to an incident if you haven't classified and identified what data is located where? Only with data classification can you provide Service Level Agreements as PART OF the incident response program.

Everything stems from classifying your data, understanding where it flows and is stored, and then placing tactical and strategic security controls in place to mitigate or eliminate risk to the integrity or loss of data.

It's the core of all great information security programs; everything else is turn-key, so spend the appropriate amount of time and thought cycles on being thorough in this area.


Justin Leapline, Senior Consultant for SecureState's Audit & Compliance practice contributed to this posting.

Read more!

Avoiding Risk – Why would you blatantly put your company at risk?

American investor and businessman Warren Buffet once said, “Risk comes from not knowing what you are doing.” I say that risks are a part of nature that is inescapable, especially in Information Technology. Risk avoidance comes from not knowing what you are doing.

When risks are identified at your organization, there are typically four options to choose from. You can accept the risk, mitigate the risk, transfer the risk, or avoid the risk. For clarification, let’s define each:

Accept the Risk – Accepting the risk is a Senior Management decision that should be made by comparing the cost of mitigating the risk to the potential impact if that risk is exploited. For instance, you discover a web vulnerability that could allow a hacker to launch a Denial of Service attack on your system. After researching the issue, you determine the cost to mitigate this risk is $25k and the potential loss if this occurs is nominal. The determination can be made that the cost to mitigate is too expensive compared to what will happen if a DoS attack occurs. Therefore, Senior Management makes the decision to accept the risk.

Mitigate the Risk – Mitigation the risk is the act of lessening, reducing, decreasing, or eliminating the risk. Using our scenario above, imagine the cost to mitigate is $25k and the potential loss is millions of dollars. The best decision will be to spend the $25k and fix the identified risk.

Transfer the Risk – Transferring the risk can occur in two different ways. You can outsource the function or process that is at risk to a third party contractually making them responsible for that risk, or you can choose to get insurance.

Avoid the Risk – Avoiding the risk is the act of doing nothing.

Avoiding the risk, in my opinion, should not even be an option on the list of possible choices. Avoidance is what people do when they are too lazy, too inexperienced, or too stubborn to realize they have a problem and they need a solution. Ignoring the issues does not make them go away. Over time, risks tend to have a snowball effect. It starts out small and manageable, but as it begins to roll down hill, the size and manageability of it becomes to enormous to handle. Now you are left extremely vulnerable and you don’t have the capabilities, resources, or knowledge to fix the problem. The only thing left to do is sit back and pray that you don’t get breached.

In our line of business, we identify risks and offer solutions to our clients. What option they choose is up to them. But avoiding the risks we have identified is not the solution; it only leaves them unsecure and vulnerable. Why anyone would do this to their organization is beyond me.

Read more!

Classic ASP SQL Injection Prevention

Undoubtedly one of the most common vulnerabilities that I run across during penetration tests or web application security assessments is SQL injection. The fix is very easy for most programming languages, however one seems to be horribly neglected on the world wide web. If you search google for SQL injection prevention along with a specific language, you will run across many forum posts suggesting fixes, many of which are incorrect or simply deterrents that don't fix the root of the problem. More specifically, there is a lack of examples online for PROPERLY preventing SQL injection on Classic ASP pages.

With that being said, simple filtration of certain characters, keywords, and other attempts to deter SQL injection are many times quite laughable to a security professional such as myself who knows many ways to circumvent such countermeasures. Aside from some of the feeble attempts at prevention I've seen, the end goal is to properly secure your resources regardless of past code written. With the lack of Classic ASP examples to properly prevent SQL injection, I am providing an example simple login page below on how to correctly and incorrectly perform database queries using Classic ASP and VBScript. There are other methods than the one shown below that work, but this seems to be the simplest. Enjoy!

<%@ Language = "VBScript" %>
<%
Option Explicit
Dim cnnLogin, rstLogin, strUsername, strPassword, strSQL
Const adCmdText = 1                  'Evaluate as a textual definition
Const adCmdStoredProc = 4            'Evaluate as a stored procedure
%>
<html>
<head><title>Login Page</title>
</head>
<body bgcolor="gray">
<%
If Request.Form("action") <> "validate_login" Then
    %>
    <form action="login.asp" method="post">
    <input type="hidden" name="action" value="validate_login" />
    <table border="0">
        <tr>
            <td align="right">Login:</td>
            <td><input type="text" name="login" /></td>
        </tr>
        <tr>
            <td align="right">Password:</td>
            <td><input type="password" name="password" /></td>
        </tr>
        <tr>
            <td align="right"></td>
            <td><input type="submit" VALUE="Login" /></td>
        </tr>
    </table>
    </form>
    <%
Else
    Set cnnLogin = Server.CreateObject("ADODB.Connection")
    cnnLogin.open "PROVIDER=SQLOLEDB;DATA SOURCE=localhost;UID=dbuser;PWD=dbpassword;DATABASE=test"

    '============================================================================================
    'BAD WAY WITH CONCATENTATION DON'T DO IT!!!
    '------------------------------------------
    strSQL = "SELECT * FROM users WHERE username='" & Request.Form("login")& "' AND password='"_
             & Request.Form("password") & "';"
    Set rstLogin = cnnLogin.Execute(strSQL)
    '============================================================================================
        
    'CORRECT WAY - Parameterized Query with dynamic sql
<!--
    strSQL = "SELECT * FROM users WHERE username=? AND password=?"
    Dim cmd1
    Set cmd1 = Server.CreateObject("ADODB.Command")    
    cmd1.ActiveConnection = cnnLogin
    cmd1.CommandText = strSQL
    cmd1.CommandType = adCmdText
    cmd1.Parameters(0) = Request.Form("login")
    cmd1.Parameters(1) = Request.Form("password")
    Set rstLogin = cmd1.Execute()
-->
    
    'CORRECT WAY - Parameterized Query with stored procedure
<!--
    Dim cmd2
    Set cmd2 = Server.CreateObject("ADODB.Command")
    cmd2.ActiveConnection = cnnLogin
    cmd2.CommandText = "login_sp"
    cmd2.CommandType = adCmdStoredProc
    cmd2.Parameters(1).Value = Request.Form("login")
    cmd2.Parameters(2).Value = Request.Form("password")
    Set rstLogin = cmd2.Execute
-->
    If Not rstLogin.EOF Then
        %>
        <p>
        <strong>Successfully Logged In!</strong>
        </p>
        <%
        Else
        %>
        <p>
        <font size="4" face="arial,helvetica"><strong>Login Failed!</strong></font>
        </p>
        <p>
        <a href="login.asp">Try Again</a>
        </p>
        <%
        'Response.End
    End If

    ' Clean Up
    rstLogin.Close
    Set rstLogin = Nothing
    cnnLogin.Close
    Set cnnLogin = Nothing
End If
%>
</body>
</html>

Read more!

Your WAN diagram better include Starbucks...

When performing a network architecture review (security focused), we always ask for LAN/WAN diagrams. Some LAN diagrams are detailed to an OCDegree, but other times we get some pretty lame ones (or none at all - even in HUGE organizations).

I often wonder - why aren't all the extensions of the WAN documented in the diagrams as well? When a remote worker with a laptop connects to your corporate network via VPN, isn't that truly an extension of your WAN?

Yes, yes it is.

Shouldn't laptops that are, in effect, extending your WAN to Starbucks and Panera be treated as assets with a higher rate of compromise associated with them? Let us go on record: the days of solely relying on the Windows Firewall and anti-virus software for laptop protection in the volatile network soup known as the Internet are LONG GONE. When a laptop connects to an open wireless network at (name your coffee shop of choice), your organization is inherently ACCEPTING all of the network vulnerabilities of that hotspot. You can't control the hosts that reside on the same network as your laptop, and you can't verify that there isn't already malicious activity taking place on that network.

What you can do:

• Use laptop images as a source of creating a Minimum Security Baseline, not just an administrative Easy Button.
  
• When deplying VPN to remote employees, don't enable Split Tunneling. Seriously, just don't do it. Full tunneling or bust. And to top it off, a web proxy would be great.
  
• HIPS or be square. That's right, Host Intrusion Prevention System. As more of the big guys implement HIPS into their anti-everything agents, the time has come to really look at implementing the technology. Steer clear of HIPS technology that is signature-based; it will never be as strong as something behavior-based. I've got my favorite, but we won't talk about that here.
  
• Network Admission Control is a good idea, just depends on how you deploy it. Enforcing security posture will always be better than what most are doing, which is nothing.
  
• Don't allow employees to install full VPN clients on their home PC's for connecting back to your corporate network. Since when was "Barbie Horse Adventures" part of your trusted app list?

All I'm asking is that you're realistic. Include everything that extends your WAN beyond your border router - which is anyONE or anyTHING connecting to your network from the outside, to name a few:

• Site-to-site VPN connections
• Remote-access VPN connections
• PDA's with sync'ing capabilities

This might be stating the obvious, but asking the question, "Does this extend the boundaries of my WAN?" is part of a good exercise while designing the management, technical, and operational controls associated with devices that are "ridin' dirty".

Read more!

"So What's Everyone Else Doing???"

As a security auditor, I can't tell you how many times I've been asked this when talking about compliance. If I only had a nickle for every time someone asked me that question... well... I'd probably want to throw it at the person who just asked me it. This is such a bad question on so many levels and it still frustrates me each time. That being said, I suppose I should answer it here so that maybe, just maybe, they won't ask next time.

My first response is, 'everyone else' is not doing a good job, not enough, and likely the wrong things. For example, take PCI compliance. Even after all this time, only 77% of Level 1 Merchants are compliant. Now if everyone is being as tough as they should be, those merchants are getting fined $25,000 per month and a possibly higher transaction rate. Compliance basically exists because when 'everyone else' was doing what 'everyone else' did, 'everyone' sucked! So somebody had to step in and raise the bar for them. It's like the flock needing a shepherd.

Now imagine that all of sudden you get breached because your 'average' organization is doing things just like 'everyone else,' which isn't enough... do you really want to stand at the podium and state that you didn't do enough because others aren't? Is that really a good, defensible position? On average, the average isn't good. So do you really want to measure yourself against them?

I think it's also ironic when you realize that just prior to this question is the statement made by the same person that "Well, we're unique here at Company X". Of course you are! If not, I can't imagine you'd have differentiators and be unique. There is no reason why that can't be security. It is probably a pretty good reason to not be like 'everyone else'. I'm hoping the next time someone asks me this, they want to know so they can use it for out marketing 'everyone else'.

Read more!

Dear NERC, CIP needs a protein shake...

We've been posting a lot of information about compliance regulation lately, so I'll just add another scoop to this steamy pile...

The North American Electric Reliability Corporation (NERC) is a self-regulatory (non-governmental) organization subject to oversight by the U.S. Federal Energy Regulatory Commission (FERC). As of June 18, 2007, FERC granted NERC the legal authority to enforce reliability standards with all U.S. users, owners, and operators of the bulk power system, and made compliance with those standards mandatory and enforceable.


The preceding paragraph came pretty much verbatim from the NERC website. Now that we have a little insight on NERC, let's stop FERC'in around and talk about Critical Infrastructure Protection (CIP).

CIP was designed to protect the United States critical infrastructure and features a heavy emphasis on safeguarding critical cyber assets (CCA) that help run the systems that generate electricity and control the transmission of electricity. The CIP standard is broken down into 8 individual requirements (CIP-002 through CIP-009) for various areas of protection or security. Audits for NERC CIP begin July 1, 2009. You might recall a certain blackout of 2003 that affected a large number of northeastern states? Hmmmmmm?? This prompted the NERC CIP standard, much like Enron prompted SOX.

As assessors or auditors, our team works with many different standards and regulations, and we've done a lot of NERC CIP related work with our energy clients over the past year. We've heard multiple complaints from clients about the CIP standard being vague or hazy, and I tend to agree. The clarity on protection levels that are expected are muddy.

As far as standards go, CIP needs a protein shake. We're talking about a standard that's designed to protect some of the country's most critical systems. It NEEDS to be stronger.

And what's with the non-standard terms in the standard? "Cyber"? "Electronic Security Perimeter"?

Really? Who uses those?

Why don't they just throw in "microcomputer" or "World Wide Web"?

While other standards and compliance reg's require penetration testing, CIP only requires vulnerability scanning. Scanning for modems is referenced quite a bit in CIP, but there's practically nothing related to wireless. Sure, there are tons of modems out there, especially in those sectors, but NERC needs to let go of 1996. Check out some of the latest breaches across the country - I can't remember the last time I read a story about a compromise being traced back to a dusty modem. (Calm down, calm down...I know it still happens, just not as frequently.) And what about the exception for nuke plants? Why can't you apply NERC CIP to nuke plants as well? Businesses have to deal with multiple compliance efforts ALL THE TIME. Why wouldn't you use CIP as a "second set of eyes" for those sites?

And one more before I move on to the positives of NERC CIP. The standard isn't a shadow of what other regulations like PCI are requiring. You mean to tell me that the standards for the companies that allow me to turn on my lights are less than those of the companies that want to swipe my plastic?

NEWS FLASH: If the power is off, no one cares about PCI, HIPAA, or SOX.

Why?

Because the 'puters, calculators, and credit card processors don't work so well without power.

On a positive note - NERC CIP outlines a great schedule for compliance, with different progression paths. It's very detailed and could be something that other regulations take note of. The standard also breaks down what can be used as measures to demonstrate compliance, as well as specific levels of non-compliance which act as a nice grading system.

All in all, the standard has some positives but plenty of negatives. In my opinion, it has a long way to go before I stop stocking up on candles.

Read more!