Two New Statements, One Read!
Are they worth the read?
Yes, but you only have to read the first one!
Another one of those Dan’s New Leaf Posts, meant to inspire thought about IT Governance . . . .
Note: If you haven’t figured it out, on 03/30/15 the FFIEC posted two new “statements.” While we do not announce new FFIEC Guidelines (as we believe most of our readership that WANTS this information is already getting it directly from their regulators) we will, from time-to-time, try to post a quick analysis, so that you can know what’s coming up, in our opinion!
Real quick summary: Read the Credentials statement first. If you aren’t implementing the controls at the bottom of this article, then read the Malware statement as well.
03/30/15 Statement #1:
Cyber Attacks Compromising Credentials
Is it worth the read?
Heck yes! It’s about four pages of reading material and though there’s not a lot new, it rephrases some important control information related to credentials.
Does it have any new requirements? Well . . . while it says, “No new regulatory expectations,” we have noticed a couple of items in the statement that we will be quoting as we try to sell our Managed Security Services. For example, event log management will need to be used to do some of the stated log monitoring requirements, and establishing the baseline is what we do during the tuning period for our IPS/IDS systems!
One thing we found interesting: In an attempt to delineate examples of attack vectors, the FFIEC defines Phishing, Spear-Phishing, Malvertising, Watering Holes, and Web-based Attacks
- Phishing and Spear-Phishing: Conducting attacks using social engineering by sending e-mails disguised as legitimate messages; tricking users into disclosing names and passwords, payment card information; or clicking on links or attachments that deliver malware to their computers.
- Malvertising: Injecting malware into legitimate online advertising and downloading the malware to the computer of any person who visits the Web site containing the advertisement.
- Watering Holes: Injecting malware into a vulnerable Web site frequented or commonly visited by targeted victims. The compromised site facilitates the downloading of malware to the computer of any person who visits the Web site.
infotex Notes about these definitions:
- In infotex lore, Spear-phishing is phishing that targets specific groups, like “employees of First Bank Nowhere,” or “all email addresses in the xyz department” whereas phishing is more of a “generic” attack.
- Malvertising: While some would argue this is a “watering hole tactic,” rather than a different vector altogether, who cares. But it is also important to add that “bloatware” and other “unwanted applications” also carry associated risks.
- Many organizations refer to Watering Holes as Drive-by Attack Sites.
Later in the document, it lists the following additional attack vectors:
- It also cites weak passwords as an exacerbating risk factor.
- System credentials may be targeted directly through vulnerabilities in authentication systems (e.g., OpenSSL “Heartbleed”)6 or indirectly by compromising the credentials of trusted third parties (e.g., fraudulent certificates).
We will be turning these into a “drill-down risk assessment” on Credentials soon!
The guidance also includes these impacts of stolen credentials, which we will be alluding to in our drill-down risk assessment:
- Stolen customer credentials may give an attacker access to customers’ account information to commit fraud and identity theft.
- Stolen employee and third-party credentials may provide initial access to trusted internal systems that may be used to leverage system administrator level access to obtain confidential business and customer information, modify and disrupt information systems, and destroy or corrupt data.
- Stolen system credentials may also be used to gain access to internal systems and data to further distribute malware or impersonate the financial institution to facilitate fraud such as accessing payment processing systems for automated clearing house transactions.
- Compromised credentials may expose financial institutions to a range of risks that include loss of the confidentiality and integrity of sensitive data, such as customer information and confidential business information.
- Further, compromised credentials enable cyber attackers to disrupt and degrade systems or process fraudulent financial transactions that may not be recovered by the institutions
The statement articulates the following controls for credentials:
- [referring to the 2005 Guidance on Authentication, and the 2011 supplement] . . . The guidance requires, among other things, security measures to reliably authenticate customers accessing their financial institutions’ Internet-based services.
- Conduct Ongoing Information Security Risk Assessments (you’ve read this a hundred different ways, we won’t rehash in this article)
- Perform security monitoring, prevention, and risk mitigation.
- Ensure protection and detection systems, such as intrusion detection systems and antivirus protection, are up-to-date and firewall rules are configured properly and reviewed periodically.
- Establish a baseline environment to enable the ability to detect anomalous behavior.
- Monitor system alerts to identify, prevent, and contain attack attempts from all sources. In addition,
- Follow software assurance industry practices for internally-developed applications. o Conduct due diligence of third-party software and services.
- Conduct penetration testing and vulnerability scans, as necessary.
- Promptly manage vulnerabilities, based on risk, and track mitigation progress, including implementing patches for all applications, services, and systems. o Review reports generated from monitoring systems and third parties for unusual behavior.
- Protect against unauthorized access (limit elevated privileges, access authorization reviews, expire unused credentials, monitor logs for use of old credentials, establish authentication rules . . . . . this section reads like an audit checklist, and if your auditors did not check for this stuff, they will now! We confess, we did not check that you’re monitoring logs for use of old credentials. Quite frankly, we are surprised that this is in the regulations, as we would have used it to point out how our ELM system is helping banks comply with the regulations. So though this document claims no new expectations, this one will probably cost you money if you are not currently managing logs beyond “checking failed logins.”
- Implement and test controls around critical systems regularly. More audit checklist stuff.
- Enhance information security awareness and training programs (thank you!)
- Participate in Industry Sharing Form (and a thank you again from FS-ISAC) but also a nod to US-CERT.
03/30/15 Statement #2:
Is it worth the read?
Well . . . . for one, half of it duplicates what’s in the Credentials Statement. But also, as we were reading it, we were thinking, “shouldn’t this already be in place?” I mean, we don’t know many banks who have not already gone through a malware incident.
Still, it points out that business continuity plans should address response and recovery from malware incidents. We have seen most of our banks include this as a separate procedure, and we are motivated to update our procedure in case anybody needs it after an examination. So, if you can’t say “already addressing that” to the following suggested controls, then you might want to read the statement. It’s only five pages!
New Regulatory Requirements?
Well again they say no, but we’re adding “test malware response plan” to our checklists.
It does define the following terms:
- Air Gap: a security measure that isolates a secure network from unsecure networks physically, electrically, and electromagnetically.
- Data mirroring: The replication of data to alternate processing sites or storage systems at regular intervals defined by recovery time periods of an organization.
Suggested Mitigating Controls:
- Securely Configure Systems and Services: a paragraph form audit checklist that you should have already undergone many times if you’re a financial institution or an organization who has been audited.
- Review, update, and test incident response and business continuity plans (another example of acting like they always wanted incident response plans tested.) But this now means they want to see Malware Response as an Attack Scenario if you are using these in your Incident Response Planning. (Ask for our procedure if you’re a Client!)
- Conduct ongoing risk assessments. (duh)
- Perform Security Monitoring, Prevention, and Risk Mitigation (if you’re reading the credentials statement you can skip this, it’s the same!)
- Protect against unauthorized access. (Same as credentials statement.)
- Implement and test controls around critical systems regularly (Same.)
- Enhance information security awareness programs (Same.)
- Participate in information sharing forms (Same.)
So as you can see, this one is almost worth the read because the last four sections have already been read (assuming you read the Credentials Statement!)
Keep an eye out for our upcoming drill-down risk assessment on credentials!
Original article by Dan Hadaway CRISC CISA CISM. Founder and Managing Partner, infotex
Dans New Leaf is a fun blog to inspire thought in the area of IT Governance.