Last Updated: 2014-05-26 16:26:04 UTC
by Tony Carothers (Version: 1)
The National Institute of Standards and Technology (NIST) Information Technology Laboratory (ITL) has announced both an updated, and a new initial draft publication, over the past two weeks that is fairly significant to most of us in the security field. The NIST ITL group is charged with ‚??promote U.S. innovation and industrial competitiveness by advancing measurement science, standards, and technology through research and development in information technology‚?Ě.
NIST ITL has published an online database of controls for NIST 800-53 rev. 4 ‚??Recommended Security Controls for Federal Information Systems and Organizations‚?Ě. This will enable organizations to quickly search and download the catalog of security controls and procedures defined in this publication. The link above contains additional information, as well as a link to the files available for download for both revisions 3 and 4 of NIST 800-53.
The second release is an initial publication of NIST 800-160 ‚??Systems Security Engineering: An Integrated Approach to Building Trustworthy Resilient Systems‚?Ě. This document is an excellent source of information for all security professionals, whether in the role of a Security Engineer as a full time position, or an Operations Analyst who is part of a ‚??one stop shop‚?? for delivery and operations of security systems. The document does a good job of explaining how Security integrates into the planning, design, and delivery of systems, and how our efforts integrate with the overall systems engineering program. I hope to have some time for a more comprehensive summary in the coming weeks as this is one of the most useful publications I‚??ve seen come out of NIST in a number of years.
tony d0t carothers --gmail
Last Updated: 2014-05-26 11:53:21 UTC
by Mark Hofman (Version: 1)
A few weeks ago I worked on a cryptodefense incident. A few things were done right in the organization and a few not so well. However in this particular instance there is a happy(ish) ending.
Cryptodefense made its appearance around February this year on the back of the success of Cryptolocker. The basics remain the same though and once infected the malware searches out PDF, doc(x), jpg and a few more document types and encrypts those. Files are encrypted using a RSA 2048 bit key which is placed in the user's AppData Directory (/Users/xxxxxx/AppData/Roaming/Microsoft/Crypto/RSA/S-1-5-21-254666440-1725212059-1820442801-6608/28093c3a55c1788ef10f8a6ac25eff17_55be799d-cb75-4e81-9059-484e3bdbf27e ). The application then starts encrypting files in various directories. From the mactime time line the /User/ directories are done first as well as the recycling bin.
Each directory containing encrypted files also has three files in them starting with HOW_DECRYPT. The file contains instructions on how to have your files decrypted after paying.
The three files provide instructions on how to decrypt the file, or more accurately provide a link to where you can pay to get the decrypt application which will use the key on your machine to decrypt your files.
The impact of this particular malware can be devastating. Looking at what is left of the hard drive every directory that looks like it may have documents or pictures in it has been touched. This includes things like dropbox and network shares. In an incident elsewhere earlier in the year external harddrives were also encrypted.
The AV product used did not pick up this particular variant, nor did the web content filters. The AV did however find some malware (possibly related) on the machine around the same time the encryption processes started. However this was not responded to by the user or IT.
So what were the lessons learned in this instance? Well for starters backups are your friend. In this particular instance the organization had good backups of the files on the servers. So those files could be replaced from the backups. The Dropbox files were also ok as they have previous versions of the document available. Local files on the machines however did not have backups, so these were essentially lost (if infected with the pre April 2014 version you may have the key)*.
The other lesson learned was to take AV responses more seriously. Just because the AV says it has cleaned something does not necessarily mean that everything is gone, only the bits it knows about. In this instance it missed the malicious files (likely part of a Bing bar installation which happened prior to the infection starting), but picked up other rubbish that was running on the machine. Possibly a coincidence, but ... The encryption process took a few hours. Had the machine been pulled of the network when the infection was noticed, fewer files would have been affected.
So in short AV is not perfect, but respond when it tells you things have been infected. Secondly have viable backups, including files on roaming machines such as laptops. If not, be prepared to fork out money or go through a painful decrypting exercise (until they start putting the keys elsewhere).
Mark H - Shearwater
*updated to clarify.