<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title>Insider Threat Blog</title>
    <link rel="alternate" type="text/html" href="https://www.cert.org/blogs/insider_threat/" />
    <link rel="self" type="application/atom+xml" href="https://www.cert.org/blogs/insider_threat/atom.xml" />
    <id>tag:www.cert.org,2010-08-19:/blogs/insider_threat//2</id>
    <updated>2013-05-06T10:40:47Z</updated>
    
    <generator uri="http://www.sixapart.com/movabletype/">Movable Type Pro 4.35-en</generator>

<entry>
    <title>Controlling the Malicious Use of USB Media</title>
    <link rel="alternate" type="text/html" href="https://www.cert.org/blogs/insider_threat/2013/05/controlling_the_malicious_use_of_usb_media.html" />
    <id>tag:www.cert.org,2013:/blogs/insider_threat//2.159</id>

    <published>2013-05-06T10:40:00Z</published>
    <updated>2013-05-06T10:40:47Z</updated>

    <summary>Hello, this is George J. Silowash, Cybersecurity Threat and Incident Analyst for the CERT Division of the Software Engineering Institute. Earlier this year, we released the report Insider Threat Control: Understanding Data Loss Prevention (DLP) and Detection by Correlating Events...</summary>
    <author>
        <name>CERT Insider Threat Center</name>
        
    </author>
    
    
    <content type="html" xml:lang="en" xml:base="https://www.cert.org/blogs/insider_threat/">
        <![CDATA[<p>Hello, this is George J. Silowash, Cybersecurity Threat and Incident Analyst for the CERT Division of the Software Engineering Institute. Earlier this year, we released the report <a href="http://www.sei.cmu.edu/library/abstracts/reports/13tn002.cfm">Insider Threat Control: Understanding Data Loss Prevention (DLP) and Detection by Correlating Events from Multiple Sources</a>. In this report, we discuss the challenges universal serial bus (USB) flash drives present to organizations, especially those concerned with protecting their intellectual property.</p>]]>
        <![CDATA[<p>Malicious insiders&rsquo; intent on stealing organizations&rsquo; sensitive information will look for any way to remove the information from systems, including the use of USB removable media. USB removable media is inexpensive, easy to conceal, and offers massive amounts of storage in a small package. Organizations need to better understand how to audit and restrict the use of these devices.</p><p>Organizations must know where their sensitive data lives before mitigation strategies can be used to protect it. Data may reside on servers, workstations, laptops, and mobile devices. Each of these devices is a potential exit point for sensitive data and must be included in the organization&rsquo;s overall risk assessment. Once an organization understands where its data lives, who has authorized access to it, and the possible exit points, mitigation strategies can then be implemented to mitigate the risk of the unauthorized data exfiltration.</p><p>In this report, we explore how Microsoft Windows operating system controls can be used to control and audit the use of USB removable media. We also look at an open-source tool for identifying where sensitive data lives. Finally, we discuss the importance of a security information and event management system for analyzing and correlating events to help paint a bigger picture of what is happening in the organization&rsquo;s information systems.</p><p>We are interested in hearing your feedback on this control. If you have questions or want to share experiences you've had with insider threats, send email to <a href="mailto:insider-threat-feedback@cert.org">insider-threat-feedback@cert.org</a>.</p>]]>
    </content>
</entry>

<entry>
    <title>How Ontologies Can Help Build a Science of Cybersecurity</title>
    <link rel="alternate" type="text/html" href="https://www.cert.org/blogs/insider_threat/2013/03/how_ontologies_can_help_build_a_science_of_cybersecurity.html" />
    <id>tag:www.cert.org,2013:/blogs/insider_threat//2.151</id>

    <published>2013-03-12T10:35:00Z</published>
    <updated>2013-03-12T10:35:34Z</updated>

    <summary><![CDATA[Hello, this is David Mundie, a Senior Member of the Technical Staff in the CERT Program. The term &quot;science of cybersecurity&quot; is a popular one in our community these days. For some time now I have advocated ontologies and controlled...]]></summary>
    <author>
        <name>CERT Insider Threat Center</name>
        
    </author>
    
    
    <content type="html" xml:lang="en" xml:base="https://www.cert.org/blogs/insider_threat/">
        <![CDATA[<p>Hello, this is David Mundie, a Senior Member of the Technical Staff in the CERT Program. The term &quot;science of cybersecurity&quot; is a popular one in our community these days. For some time now I have advocated ontologies and controlled vocabularies as an approach to building such a science. I am fond of citing the conclusion of the <a href="http://www.fas.org/irp/agency/dod/jason/cyber.pdf">Jason Report</a>, that the most important step towards a &ldquo;science of cybersecurity &quot;would be the construction of a common language and a set of basic concepts about which the security community can develop a shared understanding,&quot; or in other words, an ontology.</p>]]>
        <![CDATA[<p>In August 2012, I presented a paper on a disciplined, 10-step process for building ontologies at the <a href="http://www.allconferences.com/conferences/2012/20120222092106/">First International Workshop on Ontologies and Taxonomies for Security (SecOnt)</a> . In 2012, David McIntire and I worked with the CERT Malware Analysis team to generate a controlled vocabulary for malware analysis that has just been published as the CERT report, <a href="http://www.sei.cmu.edu/library/abstracts/reports/13tn010.cfm">The MAL: A Malware Analysis Lexicon</a>.</p><p>Most recently, I have transferred that vocabulary to a machine-processable ontology language, specifically, the <a href="http://www.w3.org/2004/OWL/">W3C's OWL</a>, or Web Ontology Language. That transfer made it possible to combine the vocabulary with a competency model that maps semantic clusters from the vocabulary onto specific job competencies. So-called Ontology-Based Competency Models have been quite popular recently, because combining rigorous models of domain knowledge with rigorous models of competencies provides a solid basis for building training programs, performance assessments, and hiring plans. Two examples are <a href="http://www.eife-l.org/publications/proceedings/ilf07/Contribution110.doc.pdf">An Ontological Approach to Competency Management </a>and <a href="http://www.cc.uah.es/msicilia/papers/SICI_COMP_05.pdf">Ontology-Based Competency Management</a>.</p><p>Although still in its infancy, we think our combination of the malware analysis vocabulary and the competency model holds a lot of promise, and hope to present it at this year's <a href="http://www.ares-conference.eu/conf/index.php?option=com_content&amp;view=article&amp;id=50&amp;Itemid=82">SecOnt workshop</a>. The following screen shot shows the top level of the ontology being edited in Stanford's <a href="http://protege.stanford.edu/">Prot&eacute;g&eacute; </a>tool.</p><p><span class="mt-enclosure mt-enclosure-image" style="display: inline"><img class="mt-image-left" alt="ontology.png" width="300" height="290" style="margin: 0px 20px 20px 0px; float: left" src="/blogs/insider_threat/2013/03/12/ontology.png" /><br />&nbsp;</span></p><p>&nbsp;</p><p>&nbsp;</p><p>&nbsp;</p><p>&nbsp;</p><p>&nbsp;</p><p>&nbsp;</p><p>&nbsp;</p><p>&nbsp;</p><p>&nbsp;</p><p>If you have questions or want more information about our work on a malware ontology, send email to <a href="mailto:insider-threat-feedback@cert.org">insider-threat-feedback@cert.org</a>.</p>]]>
    </content>
</entry>

<entry>
    <title>CERT Insider Threat Events at the RSA Conference</title>
    <link rel="alternate" type="text/html" href="https://www.cert.org/blogs/insider_threat/2013/02/cert_insider_threat_at_the_rsa_conference.html" />
    <id>tag:www.cert.org,2013:/blogs/insider_threat//2.148</id>

    <published>2013-02-19T12:01:00Z</published>
    <updated>2013-02-19T12:07:36Z</updated>

    <summary><![CDATA[Hi, this is Dawn Cappelli, Director of the CERT Insider Threat Center. The RSA Conference is rapidly approaching, and since many of you will likely be there, I thought I&rsquo;d let you know how to find us there. Also, if...]]></summary>
    <author>
        <name>CERT Insider Threat Center</name>
        
    </author>
    
    
    <content type="html" xml:lang="en" xml:base="https://www.cert.org/blogs/insider_threat/">
        <![CDATA[<p>Hi, this is Dawn Cappelli, Director of the <a href="http://www.cert.org/insider_threat/">CERT Insider Threat Center</a>. The <a href="http://365.rsaconference.com/index.jspa">RSA Conference</a> is rapidly approaching, and since many of you will likely be there, I thought I&rsquo;d let you know how to find us there. Also, if you would like to get together to discuss insider threat while you&rsquo;re there please email us at <a href="mailto:insider-threat-feedback@cert.org">insider-threat-feedback@cert.org</a> this week and we&rsquo;ll make arrangements to meet.</p>]]>
        <![CDATA[<p>Please stop by CERT booth #2059 and check out everything offered by the Software Engineering Institute and the CERT Program. We also will have two book signings for our insider threat book, <a href="http://www.sei.cmu.edu/library/abstracts/books/9780321812575.cfm?wt.ac=hpLibrary">The CERT Guide to Insider Threats</a>. Randy Trzeciak will be there on Tuesday from 11:10 to 11:40 AM and I will be there on Thursday from 11:00 to 11:30 AM.</p><p>Here is a summary of CERT Insider Threat events at RSA:</p><p><strong>Insider Threat Study: Illicit Cyber Activity Involving Fraud in the U.S. Financial Services Sector</strong><br />Monday, Feb 25, 2013<br />Presented by Randy Trzeciak of the <a href="http://www.cert.org/insider_threat/">CERT Insider Threat Center</a> and Ed Cabera of the USSS<br />This work, sponsored by DHS Science &amp; Technology, will be part of the <a href="https://365.rsaconference.com/community/connect/efg">RSA Conference eFraud Global Forum</a>. Because of the expected high interest in the topic, the presentation will be held twice during the forum: 11:30 AM and 3:15 PM.</p><p><strong>HT-R32: Intriguing Insider Threat Cases - Make Sure This Doesn&rsquo;t Happen to You!</strong><br />Thursday, Feb 28, 2013 @ 9:20 AM in Room 135<br />Presented by Dawn Cappelli, Technical Manager of the <a href="http://www.cert.org/insider_threat/">CERT Insider Threat Center</a><br />Abstract: Chances are your employees, contractors or business partners could misuse your systems with criminal intent. We collected over 800 insider threat cases for the past 12 years. This session details the most intriguing cases&mdash;some present unique mitigation challenges; others had serious results and can provide lessons learned. There will also be recommendations for mitigating these threats.</p><p><strong>STU-R37A: Studio: Intriguing Insider Threat Cases - Make Sure This Doesn&rsquo;t Happen to You!</strong><br />Thursday, Feb 28, 2013 @ 3:40 PM in Room 300<br />Presented by Dawn Cappelli, Technical Manager of the <a href="http://www.cert.org/insider_threat/">CERT Insider Threat Center</a><br />Abstract: Chances are your employees, contractors, or business partners could misuse your systems with criminal intent. We collected over 800 insider threat cases for the past 12 years. This session details the most intriguing cases&mdash;some present unique mitigation challenges; others had serious results and can provide lessons learned. There will also be recommendations for mitigating these threats.</p><p>Other CERT presentations include the following:</p><p><strong>SEM-004: Advancing Information Risk Practices Seminar (Half Day - Delegates only)</strong><br />Monday, Feb 25, 2013 @ 1:00 PM in Room 302</p><p><strong>GRC-F42: Cybersecurity SLAs: Managing Requirements at Arm&rsquo;s Length</strong><br />Friday, Mar 1, 2013 @ 10:20 AM in Room 133</p><p>Don&rsquo;t forget to email us at <a href="mailto:insider-threat-feedback@cert.org">insider-threat-feedback@cert.org</a> this week arrange to meet with us.</p>]]>
    </content>
</entry>

<entry>
    <title>Common Sense Guide to Mitigating Insider Threats - Best Practice 19 (of 19)</title>
    <link rel="alternate" type="text/html" href="https://www.cert.org/blogs/insider_threat/2013/02/common_sense_guide_to_mitigating_insider_threats_-_best_practice_19_of_19.html" />
    <id>tag:www.cert.org,2013:/blogs/insider_threat//2.147</id>

    <published>2013-02-13T12:29:00Z</published>
    <updated>2013-02-13T12:29:51Z</updated>

    <summary>Hello, this is Derrick Spooner, Cyber Threat Solutions Engineer for the CERT Program, with the last of 19 blog posts that describe the best practices fully documented in the fourth edition of the Common Sense Guide to Mitigating Insider Threats....</summary>
    <author>
        <name>CERT Insider Threat Center</name>
        
    </author>
    
    
    <content type="html" xml:lang="en" xml:base="https://www.cert.org/blogs/insider_threat/">
        <![CDATA[<p>Hello, this is Derrick Spooner, Cyber Threat Solutions Engineer for the CERT Program, with the last of 19 blog posts that describe the best practices fully documented in the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats</a>.</p>]]>
        <![CDATA[<p>The CERT Program announced the public release of the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats </a>on December 12, 2012. The guide describes 19 practices that organizations should implement across the enterprise to mitigate (prevent, detect, and respond to) insider threats, as well as case studies of organizations that failed to do so. The last of the 19 best practices follows.</p><p><em><strong>Practice 19: Close the doors to unauthorized data exfiltration.</strong></em></p><p>This practice deals with raising awareness of the myriad methods of exfiltrating sensitive organizational data and recommending solutions to combat those methods. The following items represent three high-level categories of data-egress points (an expanded list can be found in the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats</a>):</p><ul><li>Removable media (e.g., USB flash drives, DVD-RW, smartphones)</li><li>Network (e.g., cloud storage, webmail, social media, SSH)</li><li>Physical (e.g., printers, copiers, fax machines)</li></ul><p>Removable media is a significant risk due to the prevalence of data transfer volumes, including audio/visual peripherals. Solutions range from physical or software-based disabling of these devices, to monitoring, to organizational required approval of data transfer. Choosing the method used to secure devices is a delicate balance between security and productivity.</p><p>The most direct disabling of USB devices, for example, would be to use active directory group policies to completely disable copying to flash drives. Commercial tools can apply finer grained controls, such as allowing file copies but snapshotting a copy of the files for further review. Another method of controlling file copies is to require that a trusted employee perform the actual copy operation after it has been approved.</p><p>Network exfiltration can be prevented by storing sensitive information, such as source code, in an air-gapped or heavily restricted and firewalled enclave network that users can only access while physically at the organization or via thoroughly hardened workstations. Connections to trusted business partners should be monitored via full-packet capture or network-flow data, and be scrutinized as much as or even more than the organization&rsquo;s internet service provider (ISP) uplink.</p><p>Secure sockets layer (SSL) encrypted traffic poses some of the highest risk because most organizations are unable to collect detailed information about the transmission. Consider proxy solutions that decrypt, inspect, and re-encrypt SSL sessions to allow full evaluation of the traffic for sensitive data or other disguised, malicious action. Cloud-based services have become commonplace and should be restricted or monitored via the aforementioned proxy recommendation. File transfer protocols should also be restricted or monitored.</p><p>Finally, the most basic physical exfiltration methods are still commonplace. Organizations should heavily monitor printers, scanners, copiers, and fax machines to ensure that employees are not taking advantage of the ease with which these devices can exfiltrate data. Consider solutions that maintain redundant copies of all jobs submitted and periodically review these copies.</p><p>Refer to the complete fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats </a>for a comprehensive understanding of the issues and recommendations mentioned.</p><p>If you have questions or want to share experiences you've had with insider threats, send email to <a href="mailto:insider-threat-feedback@cert.org">insider-threat-feedback@cert.org</a>.</p>]]>
    </content>
</entry>

<entry>
    <title>Common Sense Guide to Mitigating Insider Threats - Best Practice 18 (of 19)</title>
    <link rel="alternate" type="text/html" href="https://www.cert.org/blogs/insider_threat/2013/02/common_sense_guide_to_mitigating_insider_threats_-_best_practice_18_of_19.html" />
    <id>tag:www.cert.org,2013:/blogs/insider_threat//2.146</id>

    <published>2013-02-11T12:23:33Z</published>
    <updated>2013-02-11T12:23:31Z</updated>

    <summary>Hello, this is Randy Trzeciak, Technical Team Lead of Research in the CERT Insider Threat Center, with the eighteenth of 19 blog posts that describe the best practices fully documented in the fourth edition of the Common Sense Guide to...</summary>
    <author>
        <name>CERT Insider Threat Center</name>
        
    </author>
    
    
    <content type="html" xml:lang="en" xml:base="https://www.cert.org/blogs/insider_threat/">
        <![CDATA[<p>Hello, this is Randy Trzeciak, Technical Team Lead of Research in the <a href="http://www.cert.org/insider_threat/">CERT Insider Threat Center</a>, with the eighteenth of 19 blog posts that describe the best practices fully documented in the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats</a>.</p>]]>
        <![CDATA[<p>The CERT Program announced the public release of the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats </a>on December 12, 2012. The guide describes 19 practices that organizations should implement across the enterprise to mitigate (prevent, detect, and respond to) insider threats, as well as case studies of organizations that failed to do so. The eighteenth of the 19 best practices follows.</p><p><em><strong>Practice 18: Be especially vigilant regarding social media.</strong></em></p><p>Insiders using social media sites or applications can intentionally or unintentionally pose a threat to an organization&rsquo;s information systems and data. It is essential that organizations develop policies that clearly state what is considered acceptable use of social media and that clearly describe the responsibilities the employee has to protect the organization&rsquo;s critical assets.</p><p>These policies must not only be created, but must also be clearly communicated and consistently enforced across the organization to ensure compliance. Finally, training should be provided to educate employees, business partners, and contractors on the risks inherent in the use of social media. They should also be trained on how to protect themselves and the organization while at work and at home.</p><p>Social media allows people to easily share information about themselves and their organizations. Information about everything from birthdays and family members to business affiliations and hobbies can all be obtained from a user&rsquo;s social media profile. This information makes employees who use social media vulnerable to possible social engineering. Malicious individuals can use this information to develop spear phishing email attacks against an organization by crafting narrowly targeted, malicious emails that seem authentic.</p><p>In addition, there are cases in which employees have intentionally posted information about the company or their customers. While employers must remain vigilant of such activity, they must also be aware of current and upcoming laws and regulations addressing social media. Some states have laws prohibiting employers from requiring candidates or employees to divulge social media user IDs and passwords.</p><p>For organizations under the jurisdiction of the <a href="http://nlrb.gov/">National Labor Relations Board</a>, reports have been issued, providing examples of both good and unenforceable organizational social media policies.</p><p>Finally, organizations should ensure that they make ownership of organizational social media accounts clear, as there has been litigation of this issue.</p><p>Challenges to addressing the use of social media in organizations include the following:</p><ol><li>Organizations may find it difficult to control and monitor what employees post on social media sites.</li><li>Organizations should have a data classification policy that establishes the protections that must be afforded to data of different sensitivity levels.</li><li>Organizations must involve legal counsel while developing and enforcing the social media usage policy.</li></ol><p>Refer to the complete fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats </a>for a comprehensive understanding of the issues and recommendations mentioned.</p><p>Check back in a few days to read about best practice 19, Close the doors to unauthorized data exfiltration, or subscribe to a feed of CERT Program blogs to be alerted when a new post is available.</p><p>If you have questions or want to share experiences you've had with insider threats, send email to <a href="mailto:insider-threat-feedback@cert.org">insider-threat-feedback@cert.org</a>.</p>]]>
    </content>
</entry>

<entry>
    <title>Common Sense Guide to Mitigating Insider Threats - Best Practice 17 (of 19)</title>
    <link rel="alternate" type="text/html" href="https://www.cert.org/blogs/insider_threat/2013/02/common_sense_guide_to_mitigating_insider_threats_-_best_practice_17_of_19.html" />
    <id>tag:www.cert.org,2013:/blogs/insider_threat//2.145</id>

    <published>2013-02-08T11:29:00Z</published>
    <updated>2013-02-08T11:30:03Z</updated>

    <summary>Hello, this is Daniel Costa, Cyber Security Solutions Developer for the CERT Program, with the seventeenth of 19 blog posts that describe the best practices fully documented in the fourth edition of the Common Sense Guide to Mitigating Insider Threats....</summary>
    <author>
        <name>CERT Insider Threat Center</name>
        
    </author>
    
    
    <content type="html" xml:lang="en" xml:base="https://www.cert.org/blogs/insider_threat/">
        <![CDATA[<p>Hello, this is Daniel Costa, Cyber Security Solutions Developer for the CERT Program, with the seventeenth of 19 blog posts that describe the best practices fully documented in the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats</a>.</p>]]>
        <![CDATA[<p>The CERT Program announced the public release of the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats </a>on December 12, 2012. The guide describes 19 practices that organizations should implement across the enterprise to mitigate (prevent, detect, and respond to) insider threats, as well as case studies of organizations that failed to do so. The seventeenth of the 19 best practices follows.</p><p><em><strong>Practice 17: Establish a baseline of normal network device behavior.</strong></em></p><p>Anomalous network activity can be a key indicator of security incidents, including insider threats. To detect anomalous activity requires that you first create a baseline of normal network activity. Establishing a trusted baseline involves identifying the following:</p><ul><li>network data points of interest</li><li>length of the baseline data collection period</li><li>methods and tools used to collect and store data</li></ul><p>Suggested network data points of interest include the following:</p><ul><li>a list of predetermined devices a given workstation or server should communicate with</li><li>VPN usage, including access times, bandwidth and resources used, source IP addresses, and geolocation information</li><li>the known set of ports and protocols in use by the network</li><li>firewall and intrusion detection system logs</li></ul><p>The longer the period of data collection is, the higher the quality of the baseline&nbsp; because longer baseline data collection periods provide data that accounts for a wider range of the organization&rsquo;s normal behaviors and trends for an organization&rsquo;s network and users. By monitoring network and user activity and comparing current activity against the established baseline, you can identify anomalous behavior and take appropriate steps to further investigate it.</p><p>The investigation of anomalous activity can lead to the detection of malicious insider activity. For example, the <a href="http://www.cert.org/insider_threat/">CERT Insider Threat Center&rsquo;s </a>collection of insider threat cases includes instances in which insiders stole an organization&rsquo;s intellectual property by accessing and downloading large volumes of information that were well beyond normal use by an average user. With an established baseline of normal network and user activity and vigilant monitoring of current activity, you can more effectively detect and respond to similar situations.</p><p>Refer to the complete fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats </a>for a comprehensive understanding of the issues and recommendations mentioned.</p><p>Check back in a few days to read about best practice 18, Be especially vigilant regarding social media, or subscribe to a feed of CERT Program blogs to be alerted when a new post is available.</p><p>If you have questions or want to share experiences you've had with insider threats, send email to <a href="mailto:insider-threat-feedback@cert.org">insider-threat-feedback@cert.org</a>.</p>]]>
    </content>
</entry>

<entry>
    <title>Common Sense Guide to Mitigating Insider Threats - Best Practice 16 (of 19) </title>
    <link rel="alternate" type="text/html" href="https://www.cert.org/blogs/insider_threat/2013/02/common_sense_guide_to_mitigating_insider_threats_-_best_practice_16_of_19.html" />
    <id>tag:www.cert.org,2013:/blogs/insider_threat//2.144</id>

    <published>2013-02-06T11:31:00Z</published>
    <updated>2013-02-06T11:31:41Z</updated>

    <summary>Hello, this is George J. Silowash, Cybersecurity Threat and Incident Analyst and Lori Flynn, Insider Threat Researcher for the CERT Program, with the sixteenth of 19 blog posts that describe the best practices fully documented in the fourth edition of...</summary>
    <author>
        <name>CERT Insider Threat Center</name>
        
    </author>
    
    
    <content type="html" xml:lang="en" xml:base="https://www.cert.org/blogs/insider_threat/">
        <![CDATA[<p>Hello, this is George J. Silowash, Cybersecurity Threat and Incident Analyst and Lori Flynn, Insider Threat Researcher for the CERT Program, with the sixteenth of 19 blog posts that describe the best practices fully documented in the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats</a>.</p>]]>
        <![CDATA[<p>The CERT Program announced the public release of the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats </a>on December 12, 2012. The guide describes 19 practices that organizations should implement across the enterprise to mitigate (prevent, detect, and respond to) insider threats, as well as case studies of organizations that failed to do so. The sixteenth of the 19 best practices follows.</p><p><em><strong>Practice 16: Develop a formalized insider threat program.</strong></em></p><p>One of the key elements to mitigating the insider threat is to have an insider threat program. It should have an enterprise-wide scope with an established vision and defined roles and responsibilities for preventing, detecting, and responding to insider incidents. An insider threat program develops clear criteria for identifying insider threats, a consistent procedure for implementing technical and nontechnical controls to prevent and/or detect malicious insider behavior, and a response plan in the event an insider does harm to the organization.</p><p>As shown in the figure below, which represents the information flow within a generic insider threat program, relevant information is gathered from many parts of the organization, but received and analyzed only by the insider threat program&rsquo;s core team and manager. Organizations in the U.S. generally use functional groups and position names shown in the figure. The insider threat program&rsquo;s core team usually consists of a representative from each of the following departments:</p><ul><li>Information Technology</li><li>Information Assurance</li><li>Human Resources</li><li>Physical Security</li><li>Legal Counsel</li></ul><span class="mt-enclosure mt-enclosure-image" style="display: inline"><img class="mt-image-none" alt="figure: information flow within a generic insider threat program" style="width: 578px; height: 325px" src="/blogs/insider_threat/info_flow.png" /></span><p>A C-level manager (or equivalent) should act as the program manager or chairperson of the insider threat program so that its members have the authority to perform the program&rsquo;s duties. While the five department representatives are key members of the program, they must work with other team members from across the organization to receive information they need to be effective.</p><p>A formal insider threat program includes members of different teams from across the enterprise on an as-needed basis. People from across the organization can fill many of the program&rsquo;s roles; however, it is important to identify these individuals and roles before an insider incident occurs. The insider threat core team&rsquo;s response plan must include a method that can be used to communicate privately in case standard communication channels are compromised.</p><p>Legal counsel participation is required for information-gathering processes to ensure that all evidence is gathered and maintained according to legal standards. Legal counsel should also ensure that information is shared properly among insider threat project members, working within the confines of the law while maintaining privacy and confidentiality. Maintaining confidentiality is important to protecting the integrity of inquiries and the reputation of innocent inquiry subjects.</p><p>These are just a few things to consider when developing an insider threat program. For a more detailed discussion, we encourage you to review best practice 16 in the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats</a>.</p><p>Check back in a few days to read about best practice 17, Establish a baseline of normal network device behavior, or subscribe to a feed of CERT Program blogs to be alerted when a new post is available.</p><p>If you have questions or want to share experiences you've had with insider threats, send email to <a href="mailto:insider-threat-feedback@cert.org">insider-threat-feedback@cert.org</a>.</p>]]>
    </content>
</entry>

<entry>
    <title>Common Sense Guide to Mitigating Insider Threats - Best Practice 15 (of 19)</title>
    <link rel="alternate" type="text/html" href="https://www.cert.org/blogs/insider_threat/2013/02/common_sense_guide_to_mitigating_insider_threats_-_best_practice_15_of_19.html" />
    <id>tag:www.cert.org,2013:/blogs/insider_threat//2.143</id>

    <published>2013-02-04T14:26:00Z</published>
    <updated>2013-02-04T14:27:40Z</updated>

    <summary>Hello, this is Randy Trzeciak, Technical Team Lead of Research in the CERT Insider Threat Center, with the fifteenth of 19 blog posts that describe the best practices fully documented in the fourth edition of the Common Sense Guide to...</summary>
    <author>
        <name>CERT Insider Threat Center</name>
        
    </author>
    
    
    <content type="html" xml:lang="en" xml:base="https://www.cert.org/blogs/insider_threat/">
        <![CDATA[<p>Hello, this is Randy Trzeciak, Technical Team Lead of Research in the <a href="http://www.cert.org/insider_threat/">CERT Insider Threat Center</a>, with the fifteenth of 19 blog posts that describe the best practices fully documented in the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats</a>.</p>]]>
        <![CDATA[<p>The CERT Program announced the public release of the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats </a>on December 12, 2012. The guide describes 19 practices that organizations should implement across the enterprise to mitigate (prevent, detect, and respond to) insider threats, as well as case studies of organizations that failed to do so. The fifteenth of the 19 best practices follows.</p><p><em><strong>Practice 15: Implement secure backup and recovery processes.</strong></em></p><p>Insiders pose a substantial threat to an organization&rsquo;s critical assets by virtue of their knowledge and access to facilities, information, and technology. Trusted insiders can bypass existing physical and electronic security measures through legitimate measures and in many instances know what controls are in place to prevent or detect suspicious activity. Despite all of the protections applied throughout the organization, it is possible that a determined insider may still cause harm. It is essential that organizations recognize the threat posed by insiders and take the necessary steps to ensure organizational resilience by implementing and regularly testing backup and recovery processes.</p><p>The backup, logging, and recovery processes should all be secure, both in terms of what is being backed up as well as where and how the backups and logs are stored. Consider implementing dual control in backup generation, logging, and recovery processes. In a number of cases in the CERT Insider Threat Database, a disgruntled IT employee was able to disrupt the backup process, steal the backup media, modify various systems logs to frame another employee for malicious activity or wipeout all evidence of the incident, hindering the organization&rsquo;s ability to recover or investigate the incident.</p><p>Backup and recovery strategies should include</p><ul><li>controlled access to the backup storage facility</li><li>controlled access to the physical media</li><li>separation of duties and the two-person rule when changes are made to the backup process</li><li>separate backup and recovery administrators</li></ul><p>Ask yourself the following questions when assessing your backup and recovery processes:</p><ul><li>Are you confident you can recover from a disruption of service to the levels specified in your service level agreements, including disruptions perpetrated by trusted insiders?</li><li>When was the last time you tested your complete recovery process for all systems and services throughout your organization?</li><li>Does your disaster recovery process include recovery from an incident committed by an insider working for a trusted business partner responsible for implementing your backup and recovery strategy?</li></ul><p>Refer to the complete fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats </a>for a comprehensive understanding of the issues and recommendations mentioned.</p><p>Check back in a few days to read about best practice 16, Develop a formalized insider threat program, or subscribe to a feed of CERT Program blogs to be alerted when a new post is available.</p><p>If you have questions or want to share experiences you've had with insider threats, send email to <a href="mailto:insider-threat-feedback@cert.org">insider-threat-feedback@cert.org</a>.</p>]]>
    </content>
</entry>

<entry>
    <title>Common Sense Guide to Mitigating Insider Threats - Best Practice 14 (of 19) </title>
    <link rel="alternate" type="text/html" href="https://www.cert.org/blogs/insider_threat/2013/02/common_sense_guide_to_mitigating_insider_threats_-_best_practice_14_of_19.html" />
    <id>tag:www.cert.org,2013:/blogs/insider_threat//2.142</id>

    <published>2013-02-01T15:50:00Z</published>
    <updated>2013-02-01T15:50:43Z</updated>

    <summary>Hello, this is Eleni Tsamitis, Insider Threat Administrator for the CERT Program, with the fourteenth of 19 blog posts that describe the best practices fully documented in the fourth edition of the Common Sense Guide to Mitigating Insider Threats....</summary>
    <author>
        <name>CERT Insider Threat Center</name>
        
    </author>
    
    
    <content type="html" xml:lang="en" xml:base="https://www.cert.org/blogs/insider_threat/">
        <![CDATA[<p>Hello, this is Eleni Tsamitis, Insider Threat Administrator for the CERT Program, with the fourteenth of 19 blog posts that describe the best practices fully documented in the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats</a>.</p>]]>
        <![CDATA[<p>The CERT Program announced the public release of the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats </a>on December 12, 2012. The guide describes 19 practices that organizations should implement across the enterprise to mitigate (prevent, detect, and respond to) insider threats, as well as case studies of organizations that failed to do so. The fourteenth of the 19 best practices follows.</p><p><em><strong>Practice 14: Develop a comprehensive employee termination procedure.</strong></em></p><p>Organizations need to have procedures in place to reduce possible insider threat risk when an employee departs from the organization. These procedures are protective measures that must encompass all aspects of the termination process. A good way to guarantee that these measures protect the organization is to make sure that there is a termination checklist. Employee accounts are closed; access is terminated; equipment is collected; and remaining employees are notified.</p><p>To revoke all organizational access to departing employees, cooperation from many departments may be required. Managers must ensure an exit interview is completed, provide final performance feedback, and determine payment disbursement for the final weeks of employment. The Finance department must ensure employees return company credit cards and close accounts. IT must terminate all accounts and points of access to the former employee&rsquo;s computer, such as email, VPN, and cloud services. All equipment belonging to the organization must also be collected and verified against inventory records. Cooperation from HR and Security departments provides the necessary paperwork for termination, reviews agreements about intellectual property and nondisclosure of information, conducts a security debriefing, and collects all issued access badges and keys from the former employee.</p><p>The CERT Insider Threat Database includes several cases that involved damage caused by former employees that were terminated but retained their company&rsquo;s physical property, including but not limited to badges, laptops, access cards, and mobile devices. This property allowed the former employee continued access to information and thus the ability to wreak havoc on company servers. A physical inventory system that tracks all equipment issued to employees is an indispensable mechanism that can be used to track the distribution of and assist in the recovery of company-owned property.</p><p>Organizations should also conduct a review of the departing employee&rsquo;s online actions during the final 30 days of employment. The review should include (1) reviewing email activity to ensure confidential information wasn&rsquo;t passed outside the organization and (2) reviewing system logs to determine if any of the organization&rsquo;s information was downloaded to removable media. If a former employee used cloud-based storage, the organization should also ensure that sensitive company information is not stored on an external server.</p><p>If remaining employees are unaware of recent terminations, they may unintentionally disclose information to former coworkers. Thus, the organization should notify all remaining employees that the terminated employee is no longer with the company. No further information needs to be disclosed.&nbsp;</p><p>Refer to the complete fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats </a>for a comprehensive understanding of the issues and recommendations mentioned.</p><p>Check back in a few days to read about best practice 15, Implement secure backup and recovery processes, or subscribe to a feed of CERT Program blogs to be alerted when a new post is available.</p><p>If you have questions or want to share experiences you've had with insider threats, send email to <a href="mailto:insider-threat-feedback@cert.org">insider-threat-feedback@cert.org</a>.</p>]]>
    </content>
</entry>

<entry>
    <title>Common Sense Guide to Mitigating Insider Threats - Best Practice 13 (of 19)</title>
    <link rel="alternate" type="text/html" href="https://www.cert.org/blogs/insider_threat/2013/01/common_sense_guide_to_mitigating_insider_threats_-_best_practice_13_of_19.html" />
    <id>tag:www.cert.org,2013:/blogs/insider_threat//2.141</id>

    <published>2013-01-30T12:40:00Z</published>
    <updated>2013-01-30T12:41:07Z</updated>

    <summary>Hello, this is Ying Han, Graduate Research Assistant of the CERT Enterprise Threat and Vulnerability Management team, with the thirteenth of 19 blog posts that describe the best practices fully documented in the fourth edition of the Common Sense Guide...</summary>
    <author>
        <name>CERT Insider Threat Center</name>
        
    </author>
    
    
    <content type="html" xml:lang="en" xml:base="https://www.cert.org/blogs/insider_threat/">
        <![CDATA[<p>Hello, this is Ying Han, Graduate Research Assistant of the CERT Enterprise Threat and Vulnerability Management team, with the thirteenth of 19 blog posts that describe the best practices fully documented in the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats</a>.</p>]]>
        <![CDATA[<p>The CERT Program announced the public release of the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats </a>on December 12, 2012. The guide describes 19 practices that organizations should implement across the enterprise to mitigate (prevent, detect, and respond to) insider threats, as well as case studies of organizations that failed to do so. The thirteenth of the 19 best practices follows.</p><p><em><strong>Practice 13: Monitor and control remote access from all end points, including mobile devices.</strong></em></p><p>As information plays an essential role in our daily business, there is an increasing need for employees to be connected to their company network from anywhere to accomplish business tasks from home or in the field. When companies cannot move quickly enough to set up remote access to their company network, they frequently do not adequately address the security of this access.</p><p>An inherent vulnerability unique to employees accessing a company network remotely is the absence of the environmental constraints that may be a deterrent against IT crimes. Without being physically present at the workplace, a disgruntled employee may be more emboldened to sabotage the company network infrastructure or exfiltrate critical data in an environment because there are no coworkers available to observe any suspicious activity.</p><p>From a remote location, an insider may be able to exfiltrate data without fear of detection and without fear of having to physically escape from the crime scene. By using a public network IP address, a device that is not owned by the insider, and only remote access credentials, it may be difficult to prove whether the crime was committed by the owner of the credential without an in-depth forensic investigation. These confounding variables may give the malicious insider the illusion that his or her identity is hidden.</p><p>A type of remote access that has recently emerged is having employees bring their own devices to work, a practice that increases the vulnerability of the organization. As a result, multiple types of devices now provide avenues to remote access through unprotected network connections. For example, smart phones connected to cellular networks can access a company network by bypassing a company&rsquo;s IT security control procedures, such as intrusion detection systems, intrusion prevention systems, network logs, and firewalls. Not only is there a risk of connecting through an untrusted cellular network, there is the risk that the access can allow the insider to exfiltrate data from anywhere.</p><p>Since business operations will require employees to have remote access to the company network, it is important for companies to recognize the different vulnerabilities that accompany that access. Companies should investigate the technical controls that can be implemented to reduce the risk of an incident and to provide valuable evidence for forensic analysis when a crime is committed.</p><p>The following is a list of best practices an organization should consider:</p><ul><li>Implement end-point logging.</li><li>Audit remote transactions regularly.</li><li>Allow remote access only via company-managed devices.</li><li>Record all remote login information, including for successful and failed login attempts.</li><li>Require authorization for remote access of critical data.</li><li>Immediately disable remote access credentials of terminating employees.</li><li>Allow remote access permission via non-organization owned devices with caution.</li></ul><p>From a security viewpoint, organizations should use the following procedures as part of the termination of an employee with remote access:</p><ul><li>Close all open connections.</li><li>Require the return of all company-owned devices.</li><li>Disable all network access credentials, including remote and local access to the firewall.</li><li>Change the passwords for all shared accounts, such as system or database administrator accounts.</li></ul><p>Refer to the complete fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats </a>for a comprehensive understanding of the issues and recommendations mentioned.</p><p>Check back in a few days to read about best practice 14, Develop a comprehensive employee termination procedure, or subscribe to a feed of CERT Program blogs to be alerted when a new post is available.</p><p>If you have questions or want to share experiences you've had with insider threats, send email to <a href="mailto:insider-threat-feedback@cert.org">insider-threat-feedback@cert.org</a>.</p><p>&nbsp;</p>]]>
    </content>
</entry>

<entry>
    <title>Common Sense Guide to Mitigating Insider Threats - Best Practice 12 (of 19)</title>
    <link rel="alternate" type="text/html" href="https://www.cert.org/blogs/insider_threat/2013/01/common_sense_guide_to_mitigating_insider_threats_-_best_practice_12_of_19.html" />
    <id>tag:www.cert.org,2013:/blogs/insider_threat//2.138</id>

    <published>2013-01-28T12:54:00Z</published>
    <updated>2013-01-28T12:54:43Z</updated>

    <summary>Hello, this is Sam Perl, Cybersecurity Analyst for the CERT Program, with the twelfth of 19 blog posts that describe the best practices fully documented in the fourth edition of the Common Sense Guide to Mitigating Insider Threats....</summary>
    <author>
        <name>CERT Insider Threat Center</name>
        
    </author>
    
    
    <content type="html" xml:lang="en" xml:base="https://www.cert.org/blogs/insider_threat/">
        <![CDATA[<p>Hello, this is Sam Perl, Cybersecurity Analyst for the CERT Program, with the twelfth of 19 blog posts that describe the best practices fully documented in the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats</a>.</p>]]>
        <![CDATA[<p>The CERT Program announced the public release of the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats</a> on December 12, 2012. The guide describes 19 practices that organizations should implement across the enterprise to mitigate (prevent, detect, and respond to) insider threats, as well as case studies of organizations that failed to do so. The twelfth of the 19 best practices follows:</p><p><em><strong>Practice 12: Use a log correlation engine or security information and event management (SIEM) system to log, monitor, and audit employee actions.</strong></em></p><p>Security and logging capabilities have reached the point where data overload is as challenging a problem as data collection. So simply logging all online events is not sufficient to protect an organization&rsquo;s infrastructure from malicious activity. Organizations have reacted by placing new emphasis on the ability to spot important connections across seemingly different but related events.</p><p>Our analysis of insider crimes in the CERT Insider Threat Database revealed that correlation of events from the following infrastructure areas would, in many cases, provide useful information to use against insiders:</p><ul><li>firewall logs</li><li>authentication attempts (successful and unsuccessful)</li><li>intrusion detection system (IDS) and intrusion prevention system (IPS) logs</li><li>web proxy logs</li><li>antivirus alerts</li><li>change management logs</li><li>physical security events (such as badging in/out logs)</li></ul><p>Organizations should implement policies and procedures for auditing, logging, and monitoring these infrastructure areas and combine them with knowledge of the organization&rsquo;s assets (see Practice 6, Know your assets) to create an effective collection and analysis capability.</p><p>Before an organization begins monitoring, it should first inform employees that their use of organizational assets, including information systems, is restricted by policy and is subject to monitoring. It should also consult with legal counsel to ensure that its procedures meet legal requirements and disclosures and do not violate employee rights.</p><p>In the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats</a>, we include</p><ul><li>protective measures that organizations can take to implement a correlation capability</li><li>expected challenges</li><li>quick wins and high impact solutions</li><li>a mapping to common standards that also mentions the use of event correlation to improve security</li></ul><p>We also describe two specific incidents where insiders made changes to the&nbsp;IT infrastructure that would have been observable had the victims implemented monitoring that included log correlation or security information and event management tools.</p><p>Refer to the complete fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats</a> for a comprehensive understanding of the issues and recommendations mentioned.</p><p>Check back in a few days to read about best practice 13, Monitor and control remote access from all end points, including mobile devices; or subscribe to a feed of CERT Program blogs to be alerted when a new post is available.</p><p>If you have questions or want to share experiences you've had with insider threats, send email to <a href="mailto:insider-threat-feedback@cert.org">insider-threat-feedback@cert.org</a>.</p>]]>
    </content>
</entry>

<entry>
    <title>Common Sense Guide to Mitigating Insider Threats - Best Practice 11 (of 19)</title>
    <link rel="alternate" type="text/html" href="https://www.cert.org/blogs/insider_threat/2013/01/common_sense_guide_to_mitigating_insider_threats_-_best_practice_11_of_19.html" />
    <id>tag:www.cert.org,2013:/blogs/insider_threat//2.140</id>

    <published>2013-01-25T12:12:00Z</published>
    <updated>2013-01-25T12:11:58Z</updated>

    <summary>Hello, this is Todd Lewellen, Cybersecurity Threat and Incident Analyst for the CERT Program, with the eleventh of 19 blog posts that describe the best practices fully documented in the fourth edition of the Common Sense Guide to Mitigating Insider...</summary>
    <author>
        <name>CERT Insider Threat Center</name>
        
    </author>
    
    
    <content type="html" xml:lang="en" xml:base="https://www.cert.org/blogs/insider_threat/">
        <![CDATA[<p>Hello, this is Todd Lewellen, Cybersecurity Threat and Incident Analyst for the CERT Program, with the eleventh of 19 blog posts that describe the best practices fully documented in the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats</a>.</p>]]>
        <![CDATA[<p>The CERT Program announced the public release of the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats</a> on December 12, 2012. The guide describes 19 practices that organizations should implement across the enterprise to mitigate (prevent, detect, and respond to) insider threats, as well as case studies of organizations that failed to do so. The eleventh of the 19 best practices follows.<br />&nbsp;<br /><em><strong>Practice 11: Institutionalize system change controls.</strong></em></p><p>This best practice is one that could have prevented a substantial number of insider attacks that we&rsquo;ve researched. While these controls are most often thought to prevent cases of IT sabotage, there are many cases of insider fraud that could have been detected and prevented if change control systems were in place. For example, let&rsquo;s look at a case from our recent <a href="http://www.sei.cmu.edu/library/abstracts/reports/12sr004.cfm">Insider Threat Study: Illicit Cyber Activity Involving Fraud in the U.S. Financial Services Sector</a>:</p><p><cite>The insider was employed as a lead software developer at a prominent credit card company. This credit card company had a rewards points program where customers could earn points based on the volume and frequency of their credit card usage. These points could later be &quot;cashed in&quot; for gift cards, services, and other items of monetary value. Due to the high transaction volume of corporate accounts, a typical corporate account would hypothetically accumulate an immense number of rewards points. Therefore, the rewards points program was set up in such a way that the back-end software would not allow corporate accounts to earn points. At an unknown date, the insider devised a scheme by which he could earn fraudulent rewards points by bypassing the back-end checks in the software and linking his personal accounts to corporate business credit card accounts of third-party companies. After compromising a coworker's domain account by guessing the password, he was able to temporarily change the database security configuration to enable him to successfully link his personal accounts to several corporate accounts. The insider would cash in the rewards points for items of value, such as gift cards to popular chain stores, and then sell them in online auctions for cash. In all, the insider was able to accumulate approximately 46 million rewards points, $300,000 of which he was able to turn into cash before being caught by internal fraud investigators. The insider admitted to the scheme and bargained with investigators to reduce his sentence if he agreed to give them information on how he changed the security configuration and how to prevent a similar occurrence from happening in the future.</cite></p><p>As you can see, a change control system could have easily and effectively detected the insider temporarily changing the security controls in the database. Had the organization audited the changes to critical configurations, the insider could have been caught well before 46 million rewards points had accumulated in his personal account.</p><p>So what type of system would be considered a &ldquo;change control system&rdquo;? Homebrew solutions are in place in many organizations, but the most prominent classification that comes to mind is Host-Based Intrusion Detection Systems (HIDS). Whereas the more commonly known Network Intrusion Detection System (NIDS) analyzes networks for suspicious traffic, a HIDS analyzes suspicious activity on any host with an &lsquo;agent&rsquo;, whether the host is a workstation, server, network appliance, or something else.</p><p>A simple and common feature of HIDS is the ability to constantly monitor a file&rsquo;s integrity, usually done through cryptographic hash algorithms. If a file&rsquo;s cryptographic hash changes, it must be because its data changed. There are many configuration files on systems that should rarely (if ever) change, so having a HIDS agent monitor these files for modification is an effective way to ensure the integrity (and therefore security) of a system.</p><p>If there are systems or applications with configurations that change regularly, such as antivirus signature databases, implementing a change control system for monitoring these data will create too much &ldquo;noise&rdquo; to effectively filter out suspicious change events. However, for critical systems with concrete configurations, change control systems are ideal.</p><p>For example, have your change control system monitor for critical network appliance changes, such as firewall and router configurations. These configurations likely don&rsquo;t change all that often, and if they do, the impact can be high. Therefore, have a HIDS or other change control system generate an alert each time a modification is made to a critical configuration. These alerts are an effective way to detect abnormal or irregular changes that have a direct impact on your organization&rsquo;s security posture.</p><p>Insider threats can severely damage an organization&rsquo;s reputation, competitive advantage, and bottom line, so be sure to take proactive measures to mitigate these costly events from occurring. Refer to the complete fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats&nbsp; </a>for a comprehensive understanding of the issues and recommendations mentioned and see how change control systems can effectively assist you in your battle against insider threats.</p><p>Check back in a few days to read about best practice 12, Use a log correlation engine or security information and event management (SIEM) system to log, monitor, and audit employee actions; or subscribe to a feed of CERT Program blogs to be alerted when a new post is available.</p><p>If you have questions or want to share experiences you've had with insider threats, send email to <a href="mailto:insider-threat-feedback@cert.org">insider-threat-feedback@cert.org</a>.</p>]]>
    </content>
</entry>

<entry>
    <title>Common Sense Guide to Mitigating Insider Threats - Best Practice 10 (of 19)</title>
    <link rel="alternate" type="text/html" href="https://www.cert.org/blogs/insider_threat/2013/01/common_sense_guide_to_mitigating_insider_threats_-_best_practice_10_of_19.html" />
    <id>tag:www.cert.org,2013:/blogs/insider_threat//2.139</id>

    <published>2013-01-23T13:06:00Z</published>
    <updated>2013-01-23T13:06:40Z</updated>

    <summary>Hello, this is Marcus Smith, a graduate assistant for the CERT Program, with the tenth of 19 blog posts that describe the best practices fully documented in the fourth edition of the Common Sense Guide to Mitigating Insider Threats....</summary>
    <author>
        <name>CERT Insider Threat Center</name>
        
    </author>
    
    
    <content type="html" xml:lang="en" xml:base="https://www.cert.org/blogs/insider_threat/">
        <![CDATA[<p>Hello, this is Marcus Smith, a graduate assistant for the CERT Program, with the tenth of 19 blog posts that describe the best practices fully documented in the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats</a>.</p>]]>
        <![CDATA[<p>The CERT Program announced the public release of the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats</a> on December 12, 2012. The guide describes 19 practices that organizations should implement across the enterprise to mitigate (prevent, detect, and respond to) insider threats, as well as case studies of organizations that failed to do so. The tenth of the 19 best practices follow.</p><p><em><strong>Practice 10: Institute stringent access controls and monitoring policies on privileged users.</strong></em></p><p>This best practice focuses on system administrators and technical or privileged users. These individuals often have the technical ability, access, and oversight-related capabilities necessary to commit and conceal malicious activity. System administrators and privileged users have greater access to systems, networks, or applications than other users, thus posing an increased risk.</p><p>According to our research, a majority of insiders who commit sabotage and more than half of those who steal confidential or proprietary information hold technical positions at the victim organizations. Examples of technically sophisticated methods of carrying out and concealing malicious activity have included:</p><ul><li>creating backdoor accounts</li><li>installing remote system administration tools</li><li>modifying system logs</li></ul><p>Separating duties and requiring actions by multiple users address the need for stringent access controls and monitoring policies on privileged users. An organization must employ at least two system administrators to enforce separation of duties, which may be difficult for small organizations. A privileged user can be prevented from maliciously altering the system if he or she is not permitted or technically able to release changes to the production environment without action by at least one other user.</p><p>Organizations should consider having privileged users sign a privileged user agreement or rules of behavior that outlines what is required of them. In addition, organizations must be especially careful to disable system access to former system administrators and technical or privileged users. Many of the malicious insiders documented in the CERT insider threat database were former employees of the victim organizations.</p><p>Refer to the complete fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threat</a> for a comprehensive understanding of the issues and recommendations mentioned.</p><p>Check back in a few days to read about best practice 11, Institutionalize system change controls, or subscribe to a feed of CERT Program blogs to be alerted when a new post is available.</p><p>If you have questions or want to share experiences you've had with insider threats, send email to <a href="mailto:insider-threat-feedback@cert.org">insider-threat-feedback@cert.org</a>.</p>]]>
    </content>
</entry>

<entry>
    <title>Common Sense Guide to Mitigating Insider Threats - Best Practice 9 (of 19) </title>
    <link rel="alternate" type="text/html" href="https://www.cert.org/blogs/insider_threat/2013/01/common_sense_guide_to_mitigating_insider_threats_-_best_practice_9_of_19.html" />
    <id>tag:www.cert.org,2013:/blogs/insider_threat//2.137</id>

    <published>2013-01-21T11:20:00Z</published>
    <updated>2013-01-21T11:23:04Z</updated>

    <summary>Hello, this is Mike Albrethsen, Information Systems Security Analyst for the CERT Program, with the ninth of 19 blog posts that describe the best practices fully documented in the fourth edition of the Common Sense Guide to Mitigating Insider Threats....</summary>
    <author>
        <name>CERT Insider Threat Center</name>
        
    </author>
    
    
    <content type="html" xml:lang="en" xml:base="https://www.cert.org/blogs/insider_threat/">
        <![CDATA[<p>Hello, this is Mike Albrethsen, Information Systems Security Analyst for the CERT Program, with the ninth of 19 blog posts that describe the best practices fully documented in the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats</a>.</p>]]>
        <![CDATA[<p>The CERT Program announced the public release of the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats</a> on December 12, 2012. The guide describes 19 practices that organizations should implement across the enterprise to mitigate (prevent, detect, and respond to) insider threats, as well as case studies of organizations that failed to do so. The ninth of the 19 best practices follows.</p><p><em><strong>Practice 9: Define explicit security agreements for any cloud services, especially access restrictions and monitoring capabilities.</strong></em></p><p>It is important that organizations and their cloud providers have explicit agreements in place that address security services related to cloud environments. These agreements help to ensure that the organization can extend current security policies in its own infrastructure to the cloud infrastructure, which may be under the control of trusted third parties. In addition to understanding what the cloud provider will be doing, organizations must understand potential vulnerabilities associated with using a cloud environment.</p><p>The GAO identifies four types of cloud providers that are currently available to organizations:</p><ol><li>Private cloud&mdash;operated solely for one organization<br />&nbsp;</li><li>Community cloud&mdash;shared by several organizations<br />&nbsp;</li><li>Public cloud&mdash;available to any customer<br />&nbsp;</li><li>Hybrid cloud&mdash;two or more clouds (private, community, or public) that are connected</li></ol><p>In the community and public cloud models, organizations must trust outside employees with access to their infrastructure. The same protections that the organization uses to secure its data and infrastructure should extend to the service provider. Regular audits and monitoring are recommended to ensure that agreements are being honored, to ensure that attacks are detected, and to help the organization fully understand the cloud infrastructure being used.</p><p>In a cloud environment, new access paths to an organization&rsquo;s critical assets are created that can be exploited by attackers. In particular, malicious insiders employed by the cloud provider can have significant access to the systems and the information stored within. To effectively assess threats, a thorough understanding of what type of control is afforded to administrators who have access to the underlying hardware, hypervisors, administrative interfaces, and management tools that are used to run the cloud itself is required. This level of understanding highlights the importance of also understanding the vetting process for employees of the service provider. In addition to threats from privileged users, vulnerabilities associated with the cloud infrastructure itself should be considered.</p><p>Refer to the complete fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats</a> for a comprehensive understanding of the issues and recommendations mentioned.</p><p>Check back in a few days to read about best practice 10, Institute stringent access controls and monitoring policies on privileged users, or subscribe to a feed of CERT Program blogs to be alerted when a new post is available.</p><p>If you have questions or want to share experiences you've had with insider threats, send email to <a href="mailto:insider-threat-feedback@cert.org">insider-threat-feedback@cert.org</a>.</p>]]>
    </content>
</entry>

<entry>
    <title>Common Sense Guide to Mitigating Insider Threats - Best Practice 8 (of 19)</title>
    <link rel="alternate" type="text/html" href="https://www.cert.org/blogs/insider_threat/2013/01/common_sense_guide_to_mitigating_insider_threats_-_best_practice_8_of_19.html" />
    <id>tag:www.cert.org,2013:/blogs/insider_threat//2.135</id>

    <published>2013-01-18T12:45:00Z</published>
    <updated>2013-01-18T12:45:24Z</updated>

    <summary>Hello, this is Jeremy Strozer, Senior Cyber Security Specialist for the CERT Program, with the eighth of 19 blog posts that describe the best practices fully documented in the fourth edition of the Common Sense Guide to Mitigating Insider Threats....</summary>
    <author>
        <name>CERT Insider Threat Center</name>
        
    </author>
    
    
    <content type="html" xml:lang="en" xml:base="https://www.cert.org/blogs/insider_threat/">
        <![CDATA[<p>Hello, this is Jeremy Strozer, Senior Cyber Security Specialist for the CERT Program, with the eighth of 19 blog posts that describe the best practices fully documented in the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats</a>.</p>]]>
        <![CDATA[<p>The CERT Program announced the public release of the fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats</a> on December 12, 2012. The guide describes 19 practices that organizations should implement across the enterprise to mitigate (prevent, detect, and respond to) insider threats, as well as case studies of organizations that failed to do so. The eighth of the 19 best practices follows.<br />&nbsp;<br /><em><strong>Practice 8: Enforce separation of duties and least privilege.</strong></em></p><p>This practice is relevant to HR, Legal, Physical Security, and IT departments as well as data owners and software engineers in an organization. The goal of this practice is to limit the damage that malicious insiders can inflict by implementing separation of duties and least privilege in business processes, including Information Technology, by making technical modifications to critical systems and information.</p><p>Separation of duties requires dividing functions among multiple people to limit the possibility that one employee could harm an organization without the cooperation of others. In general, employees are less likely to engage in malicious acts if they must collaborate with other employees. Ideally, organizations should include separation of duties in the design of their business processes and enforce these processes through technical and nontechnical means.</p><p>Effective separation of duties also requires implementation of least privilege, which means authorizing people to use only the resources needed to do their job. Organizations must manage least privilege as an ongoing process, particularly when employees move through the organization as a result of promotions, transfers, relocations, and demotions.</p><p>These privileges can be controlled using physical, administrative, and technical means. Access control based on separation of duties and least privilege is crucial to mitigating the threat of an insider attack. These principles apply in both the physical and virtual worlds where organizations need to prevent employees from gaining physical or online access to resources not required by their work roles.</p><p>There are challenges to implementing separation of duties and least privileges.&nbsp; Small organizations find it more difficult to implement separation of duties and least privilege security models because they may not be staffed to accommodate these practices. Implementing these practices at a granular level may also interfere with business processes. Most organizations find it challenging to strike a balance between implementing these recommendations and accomplishing the organization&rsquo;s mission. Despite these hurdles, some quick wins and high-impact solutions are not only possible, but highly recommended.</p><p>Quick Wins and High-Impact Solutions</p><ul><li>Carefully audit user access permissions when an employee changes roles in the organization to avoid privilege creep. In addition, audit user access permissions at least annually, to remove permissions that are no longer needed.</li><li>Establish account management policies and procedures and regularly audit account activity to ensure it reconciles with the documentation.</li><li>Require privileged users to have both an administrative account with the minimum necessary privileges to perform their duties and a standard account that is used for every day, non-privileged activity.</li></ul><p>Large organizations can also review positions in the organization that include responsibility for handling sensitive information or performing critical functions. Ensure that employees in these positions cannot perform these critical functions without oversight and approval. For example, backup and restore tasks are often overlooked. One person should not be permitted to perform both backup and restore functions. The organization should separate these roles and regularly test backup and recovery processes (including the media and equipment). In addition, someone other than the backup and restore employees should transport backup tapes off site.</p><p>Refer to the complete fourth edition of the <a href="http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm">Common Sense Guide to Mitigating Insider Threats</a> for a comprehensive understanding of the issues and recommendations mentioned.</p><p>Check back in a few days to read about best practice 9, Define explicit security agreements for any cloud services, especially access restrictions and monitoring capabilities, or subscribe to a feed of CERT Program blogs to be alerted when a new post is available.</p><p>If you have questions or want to share experiences you've had with insider threats, send email to <a href="mailto:insider-threat-feedback@cert.org">insider-threat-feedback@cert.org</a>.</p>]]>
    </content>
</entry>

</feed>
