FYI - February 6, 2015 - NCUA - Financial Regulators Release New Appendix to Business Continuity Planning Booklet - Appendix J: Strengthening the Resilience of Outsourced Technology Services - The Federal Financial Institutions Examination Council members today issued a revised Business Continuity Planning Booklet, which is part of the FFIEC Information Technology Examination Handbook. The update consists of the addition of a new appendix, entitled Strengthening the Resilience of Outsourced Technology Services.   www.ncua.gov/News/Pages/NW20150206FFIECAppendixJ.aspx

FYI - Car hacking report explores lack of real-time response capabilities - A senator has released a report on security and privacy concerns facing U.S. drivers, which includes a troubling, though not surprising, finding that most automakers lack the ability to respond to intrusions in real-time. http://www.scmagazine.com/senators-report-shows-troubling-security-privacy-risks-for-drivers/article/397221/

FYI - Majority of broker-dealers report having experienced a cyber attack - Nearly 90 percent of broker-dealers and 74 percent of registered investment advisers have experienced cyber attacks either directly or via one or more of their vendors, a study from the Office of Compliance Inspections and Examinations (OCIE) found. http://www.scmagazine.com/office-of-compliance-inspections-and-examinations-issues-cybersecurity-study/article/397191/

FYI - NIST requests final comments on ICS security guide - The National Institute of Standards and Technology (NIST) is updating its security guide for industrial control systems (ICS) to include tailored guidance for utilities, automakers, chemical firms and other companies that utilize such systems. http://www.scmagazine.com/nist-requests-final-comments-on-ics-security-guide/article/397751/

FYI - NYDFS issues report, announces targeted security assessments for insurance companies - Insurance providers in New York dedicate seven percent or less of overall budgets for information security, and the majority – 95 percent – believe that they have adequate staffing levels for information security. http://www.scmagazine.com/nydfs-issues-report-announces-targeted-security-assessments-for-insurance-companies/article/397748/

ATTACKS, INTRUSIONS, DATA THEFT & LOSS

FYI - Mandiant speaks on Anthem attack, custom backdoors used - Mandiant, the incident response firm tapped by Anthem Inc. in the wake of its massive breach, says that the “sophisticated” cyber attack against the health care company involved the use of custom backdoors, one indication that an “advanced attack” did indeed take place against the company. http://www.scmagazine.com/anthem-brings-in-mandiant-to-investigate-resolve-breach/article/396749/

FYI - Tax fraud concerns prompts TurboTax developer to pause state e-filings - Intuit – developer of TurboTax, QuickBooks and Quicken – announced on Friday that it is working with state governments to address a growing tax fraud problem. http://www.scmagazine.com/tax-fraud-concerns-prompts-turbotax-developer-to-pause-state-e-filings/article/396991/

FYI - Chipotle Twitter account hacked - Chipotle's Twitter account was hacked on Sunday and attackers sent out obscene tweets in addition to changing the brand's profile image. http://www.scmagazine.com/chipotle-twitter-account-hacked-racist-messages-posted/article/397049/

FYI - Phoenix House notifies current and former employees of potential data incident - Nonprofit drug and alcohol rehabilitation organization Phoenix House is notifying about 2,000 employees and former employees that a former consultant – who had access to personal information – appears to have made unauthorized changes to the electronic payroll system hosted by third parties. http://www.scmagazine.com/phoenix-house-notifies-current-and-former-employees-of-potential-data-incident/article/397323/

FYI - Attack spike against Utah gov't computers may be work of hacktivists - Experts believe that a Salt Lake City-based NSA data center may have drawn the ire of hacktivists – which may explain a significant spike in attacks against Utah state computers in the past two years. http://www.scmagazine.com/nsa-data-center-may-have-been-targeted-by-hacktivists/article/397724/

Return to the top of the newsletter

WEB SITE COMPLIANCE - We continue the series regarding FDIC Supervisory Insights regarding Incident Response Programs.  (3of 12)

Elements of an Incident Response Program

Although the specific content of an IRP will differ among financial institutions, each IRP should revolve around the minimum procedural requirements prescribed by the Federal bank regulatory agencies. Beyond this fundamental content, however, strong financial institution management teams also incorporate industry best practices to further refine and enhance their IRP. In general, the overall comprehensiveness of an IRP should be commensurate with an institution's administrative, technical, and organizational complexity.

Minimum Requirements

The minimum required procedures addressed in the April 2005 interpretive guidance can be categorized into two broad areas: "reaction" and "notification." In general, reaction procedures are the initial actions taken once a compromise has been identified. Notification procedures are relatively straightforward and involve communicating the details or events of the incident to interested parties; however, they may also involve some reporting requirements.  Below lists the minimum required procedures of an IRP as discussed in the April 2005 interpretive guidance.

Develop reaction procedures for:

1) assessing security incidents that have occurred;
2) identifying the customer information and information systems that have been accessed or misused; and
3)containing and controlling the security incident.

Establish notification procedures for:

1) the institution's primary Federal regulator;
2) appropriate law enforcement agencies (and filing Suspicious Activity Reports [SARs], if necessary); and
3) affected customers.

Return to the top of the newsletter

FFIEC IT SECURITY - We continue our series on the FFIEC interagency Information Security Booklet.

INSURANCE  (Part 1 of 2)

Insurance coverage is rapidly evolving to meet the growing number of security-related threats. Coverage varies by insurance company, but currently available insurance products may include coverage for the following risks:

! Vandalism of financial institution Web sites,
! Denial - of - service attacks,
! Loss of income,
! Computer extortion associated with threats of attack or disclosure of data,
! Theft of confidential information,
! Privacy violations,
! Litigation (breach of contract),
! Destruction or manipulation of data (including viruses),
! Fraudulent electronic signatures on loan agreements,
! Fraudulent instructions through e - mail,
! Third - party risk from companies responsible for security of financial institution systems or information,
! Insiders who exceed system authorization, and
! Incident response costs related to the use of negotiators, public relations consultants, security and computer forensic consultants, programmers, replacement systems, etc.

Financial institutions can attempt to insure against these risks through existing blanket bond insurance coverage added on to address specific threats. It is important that financial institutions understand the extent of coverage and the requirements governing the reimbursement of claims. For example, financial institutions should understand the extent of coverage available in the event of security breaches at a third - party service provider. In such a case, the institution may want to consider contractual requirements that require service providers to maintain adequate insurance to cover security incidents.

When considering supplemental insurance coverage for security incidents, the institution should assess the specific threats in light of the impact these incidents will have on its financial, operational, and reputation risk profiles. Obviously, when a financial institution contracts for additional coverage, it should ensure that it is aware of and prepared to comply with any required security controls both at inception of the coverage and over the term of the policy.

Return to the top of the newsletter

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY - We continue the series on the National Institute of Standards and Technology (NIST) Handbook.

Chapter 19 - CRYPTOGRAPHY

19.3.2 Deciding on Hardware vs. Software Implementations

The trade-offs among security, cost, simplicity, efficiency, and ease of implementation need to be studied by managers acquiring various security products meeting a standard. Cryptography can be implemented in either hardware or software. Each has its related costs and benefits.

In general, software is less expensive and slower than hardware, although for large applications, hardware may be less expensive. In addition, software may be less secure, since it is more easily modified or bypassed than equivalent hardware products. Tamper resistance is usually considered better in hardware.

In many cases, cryptography is implemented in a hardware device (e.g., electronic chip, ROM-protected processor) but is controlled by software. This software requires integrity protection to ensure that the hardware device is provided with correct information (i.e., controls, data) and is not bypassed. Thus, a hybrid solution is generally provided, even when the basic cryptography is implemented in hardware. Effective security requires the correct management of the entire hybrid solution.

19.3.3 Managing Keys

The proper management of cryptographic keys is essential to the effective use of cryptography for security. Ultimately, the security of information protected by cryptography directly depends upon the protection afforded to keys.

All keys need to be protected against modification, and secret keys and private keys need protection against unauthorized disclosure. Key management involves the procedures and protocols, both manual and automated, used throughout the entire life cycle of the keys. This includes the generation, distribution, storage, entry, use, destruction, and archiving of cryptographic keys.

With secret key cryptography, the secret key(s) should be securely distributed (i.e., safeguarded against unauthorized replacement, modification, and disclosure) to the parties wishing to communicate. Depending upon the number and location of users, this task may not be trivial. Automated techniques for generating and distributing cryptographic keys can ease overhead costs of key management, but some resources have to be devoted to this task. FIPS 171, Key Management Using ANSI X9.17, provides key management solutions for a variety of operational environments.

Public key cryptography users also have to satisfy certain key management requirements. For example, since a private-public key pair is associated with (i.e., generated or held by) a specific user, it is necessary to bind the public part of the key pair to the user.

In a small community of users, public keys and their "owners" can be strongly bound by simply exchanging public keys (e.g., putting them on a CD-ROM or other media). However, conducting electronic business on a larger scale, potentially involving geographically and organizationally distributed users, necessitates a means for obtaining public keys electronically with a high degree of confidence in their integrity and binding to individuals. The support for the binding between a key and its owner is generally referred to as a public key infrastructure.

Users also need to be able enter the community of key holders, generate keys (or have them generated on their behalf), disseminate public keys, revoke keys (in case, for example, of compromise of the private key), and change keys. In addition, it may be necessary to build in time/date stamping and to archive keys for verification of old signatures.