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.
- 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.
- 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.
- 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.
- 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.
ATTACKS, INTRUSIONS, DATA THEFT & LOSS
- 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
- 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.
- 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.
- 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.
- 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.
Return to the top
of the newsletter
WEB SITE COMPLIANCE -
We continue the series
regarding FDIC Supervisory Insights regarding
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
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.
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
! Vandalism of financial institution Web sites,
! Denial - of - service attacks,
! Loss of income,
! Computer extortion associated with threats of attack or disclosure
! 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
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
NATIONAL INSTITUTE OF STANDARDS
AND TECHNOLOGY -
the series on the National Institute of Standards and Technology
Chapter 19 - CRYPTOGRAPHY
19.3.2 Deciding on Hardware vs.
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
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
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
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
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.