Lesson 29 of 33
In Progress

Non-attribution Process

1                 Introduction

1.1             Purpose

This document is a process guide and reference for KPMG GSOC personnel for the Non-attribution process.  The purpose of the process is to ensure that there is clear guidance to GSOC analysts to support safe use of the Internet in a way that supports rapid and accurate analysis and intelligence research while reducing the risk of attribution of their patterns of Internet use to KPMG.

1.2             Scope

This process document does not go into elaborate detail, provide low-level technical procedures, or address all potential outcomes or failure cases.  Analysts are expected to maintain and rely on technical work notes, standard operating procedures, and controls to guide their execution of this process, and expected to use their best judgment when minor adaptations are needed.  This process does not exempt GSOC analysts from their obligation to use GSOC Internet access resources for only legal purposes directly related to performance of their job.

1.3             Ownership

This document is ultimately owned by the GSOC Director.  He or she is responsible for ensuring that this is updated and maintained in response to feedback from GSOC Analysts.

1.4             Audience

This document is intended for all GSOC members (see Section 2.8 – Responsibilities).

1.5             Change Management Cycle

This document should be reviewed on at least a 6 month basis, or at any time that the Constraints or Assumptions (see Appendix) are believed to have changed.

1.6             Exceptions

Exceptions to this process can be temporarily authorized by the Head of the GSOC.  Documentation of any process exceptions must be provided to GSOC management for potential process modifications.

1.7             Reporting Violations

Failure to adhere to this process must be reported to the L3, GSOC Operations Manager, and the Head of the GSOC.

1.8             Responsibilities

The following roles have overall responsibility for elements of this process.  Please note that these are not comprehensive listings of responsibilities of each of the following roles, but represent these roles’ specific responsibilities to support the Non-attribution.

1.8.1          GSOC Director

The GSOC Director is ultimately responsible for the proper functioning of the Non-attribution process, and to ensure that supporting processes are also healthy.  He or she must ensure that this process is reviewed and adjusted on at least a 6-month basis, and authorize process adjustments on a more frequent basis if needed.  When exceptions to this processes are requested, he has the sole responsibility to ensure that any risks to the KPMG brand are communicated to the appropriate level.

1.8.2          GSOC L1, L2 and Threat/Intel Analysts

The GSOC L1 and L2 Analysts are users of the non-attribution process.  They will use the guidance within this process to ensure that they use the appropriate mechanisms to access the Internet, and that searches and investigation using the Internet will be conducted within the boundaries described by this process.  They will escalate when they identify accidental leakages or instances of potential attribution, when non-attribution systems and processes are not functioning properly, and identify and communicate issues with the Non-attribution process.

1.8.3          GSOC L3 Analyst

The GSOC L3 Analyst is also a user of the non-attribution process similar to the GSOC L1, L2, and Threat/Intel Analysts, but also provides day-to-day oversight of the proper functioning of the Non-attribution process.  The most significant role of the GSOC L3 Analyst is to approve specific high-risk activities detailed in this process.  He or she also ensures that GSOC members have the proper tools and training to access the Internet, creating guidance for specific tool usage, and recommending changes to the process to ensure process goals are met and GSOC Internet access mechanisms are sufficient.

1.8.4          GSOC Operations Manager

The GSOC Operations Manager periodically reviews how GSOC L1, L2, Threat/Intel, and L3 analysts are accessing the Internet, what they are accessing, and ensuring that technology that supports tracking of Internet access is functioning.

1.8.5          GSOC Tooling Engineer

The GSOC Tooling Engineer is the maintainer of all specialized GSOC-owned infrastructure (i.e., Darkline) used for Internet access, and manages requirements provided to KPMG UK for maintenance of KPMG infrastructure (VDI, Remote Desktop) used to access the Internet.  They are responsible for ensuring that Internet access is provided safely and securely, and that mechanisms used to track access are maintained.

1.9             Upstream (Dependent) Processes

  • Data-handing and Privacy Process

1.10        Downstream (Affected) Processes

  • Triage Process
  • Investigation Process
  • Change Management Process
  • Threat Intelligence Process

2                 Process Overview and Considerations

The Non-attribution process combines guidance about proper Internet browsing habits, with guidance to assist GSOC members to analyse and assess what type of browsing mechanism to use for Internet access.

The types of Internet access used by GSOC members will break down into the following categories, and with the following requirements for Internet access.

Approved Activities

Access CategoryDetailsAllowable Access Mechanism(s)Supporting Controls
Normal browsingNormal browsing (other than specific activities listed below) of Internal KPMG sites, general public Internet browsing associated with GSOC Operations, general security researchNormal KPMG systems (UK laptops)Existing Acceptable Use Agreements and technical controls on Internet access
Security Incident Indicator Safe 3rd Party ResearchUse of large, L3-approved sites (e.g., Virustotal, Google, Robtex) for research into indicators not suspected of Threat Actor association.GSOC VDI/Remote Desktop infrastructure and supported browserExisting User Acceptance Agreement and technical controls on Internet access
Security Incident Indicator Unapproved 3rd Party ResearchUse of small or unapproved sites (e.g., blogs) for research into indicators not suspected of Threat Actor AssociationDarkline systemDarkline logging process
Security Incident Suspected Threat Actor Indicator ResearchInternet research of any indicator associated with a suspected targeted Threat ActorDarkline system with TOR activatedAccess requires L3 approval and limitations L2 or higher only Darkline logging process
Blocked Security Site Research      Non-interactive reading or analysis of blogs, forums, etc., not accessible from normal KPMG network due to security controlDarkline systemDarkline logging process
Blocked DownloadDownload of code, image, not accessible from normal KPMG network due to security controlDarkline systemDarkline logging process L2 or higher only
Potential Malicious Site ResearchAccessing websites which potentially are delivering malicious code or exploitsHardened Darkline systemDarkline logging process L2 or higher only
Malicious Site HoneyclientAccessing websites which are delivering malicious code or exploits, in order to run the exploit code and conduct dynamic analysis of the exploit or follow-on downloads.Custom Darkline system, possibly with other network access restrictions.Access requires L3 approval and limitations Darkline logging process L2 or higher only  
Interactive Internet security researchLogging into or posting information on security forums, interacting or listening to an IRC channelDarkline system with TOR activatedAccess requires L3 approval and limitations L2 or higher only Darkline logging process

Prohibited Activities

Access CategoryProhibitedDetailsExamples
AnyNon-anonymous or non-approved Threat Actor ResearchResearch on any site, IP, domain, or URL associated with a TLP-Red or TLP-Amber indicator or that could be associated with a targeted threat actor without using TOR or without L3 approvalGoogling an IP associated with a TLP-Red/Amber threat actor from the Darkline with TOR without L3 approval
AnySupport or commission of illegal activitiesAny interaction with groups suspected of illegal activities which could be perceived as supporting or helping them.Interacting with a cybercrime ring on an underground forum using a persona and helping resolve a technical issue to build rapport
AnyAgreement to any T&C for site access w/o legal reviewAny explicit (click-through required) agreement to terms and conditions for access to a web-site.Many web-sites have click through agreements in order to access the site.  This cannot be executed without a legal review. 
AnyViolation of code of ethicsAny violation of a code of ethics for a certification that a GSOC member maintains in good standingSeveral industry certifications (CISSP, GIAC) include code of ethics.  GSOC Analysts remain bound by these codes.
AnyIntentional download of or access to any pornography-related imagesAny intentional access to pictures which could be considered to be pornography, either by downloading or browsing of a site which hosts them.Browsing an underground forum known to include pornographic pictures without some form of image-blocking software

2.1             Goal

The goal of the Non-attribution process is to ensure that the following criteria have been met:

  • GSOC Members can get data they need to support research into active security incidents, to conduct research into specific targeted threat actors, and to conduct general security research.
  • Internet research by GSOC members which could damage the KPMG brand is anonymized in a fashion which reduces the likelihood of attribution to KPMG.
  • Internet research of GSOC members does not tip off or inform potential attackers or adversaries of an investigation.
  • GSOC members can conduct research of potentially malicious Internet sites in a way that reduces the risk of compromise or exploit of GSOC infrastructure.

2.2             Normal browsing

Normal Internet browsing by GSOC members will continue using existing systems, using existing acceptable use agreements, in accordance with current KPMG controls and limitations on Internet use.  “Normal Internet browsing” constitutes browsing of Internet sites which is typical of and approved for KPMG employees NOT associated with the GSOC.  Any access to sites which support or are associated with GSOC operations (i.e., exceptions to what constitutes “normal Internet browsing”) is provided in additional detail below (paragraphs 3.3 through 3.10).

2.3             Security Incident Indicator Safe 3rd Party Research

In order to rapidly analyse security incidents, GSOC Analysts require the ability to rapidly pivot on security incident data from security analysis systems (i.e., SA, CRITS), using tools such as browser plugins, to provide additional data about indicators (e.g., ip addresses, domain names, URL’s, etc.,) associated with security incidents.  Accordingly, it is expected that there will be some sites that GSOC Analysts can rapidly go to (via browser plugin or direct access) in order to validate the potential threat of an IP address, domain name, URL, filename, or other indicator.

This access will be conducted using the approved GSOC platform (generally speaking a VDI image or Remote Desktop session provided by KPMG UK, or in business continuity cases potentially a KPMG UK laptop),

Key restrictions on this particular type of research:

  • It can only be to a site (or using a browser plugin) on a list that has been approved by the GSOC L3 Analyst (exceptions not on this list are dealt with in section 3.4)
  • It cannot be a TLP-Red or TLP-Amber indicator that could be associated with a targeted threat actor (details in section 3.5)
  • It does _not_ permit clicking through google links or cached pages, due to the fact that the referrer information, which includes search terms, can be provided to the site referred to by links.

2.4             Security Incident Indicator Unapproved 3rd Party Research

In some cases, there will be additional research that can be conducted on the Internet for indicators, such as connecting to malware analysis sites not approved by the L3, or going to unknown sites referenced in google searches.  This class of research will be conducted using the Darkline system, which allows Internet searches and access which do not contain an IP address associated with KPMG.

Key restrictions on this particular type of research:

  • It cannot be a TLP-Red or TLP-Amber indicator that could be associated with a targeted threat actor (details in section 3.5)
  • All searches must avoid association with any KPMG-specific data (Names, Internal IP addresses, filenames, etc.).

2.5             Security Incident Suspected Threat Actor Indicator Research

In some cases, KPMG will have indicator data about potential or confirmed targeted threat actors, such as IP addresses, URL’s, individual names, etc., This data, if released to the Internet, needs to be very carefully screened to ensure that threat actors are not aware of the fact that KPMG has such indicators, and to limit the possibility of broader awareness of the existence of the indicators.  Typically, these indicators will be identified as TLP-Red or TLP-Amber due to the fact that sharing the knowledge of these indicators in any way could inform a threat actor that the KPMG GSOC is aware of their existence.  Even searching for these indicators on 3rd party sites can be problematic, due to the likely compromise of some TOR exit-nodes by nation-state groups.

These indicators cannot be researched, even using the Darkline and TOR, without careful consideration by the L3 Analyst.  A targeted threat actor may use a resource (code, host, domain) only for KPMG, and the act of researching that code, host, or domain may be sufficient to inform the threat actor that KPMG has become aware of the intelligence.

The L3 Analyst must consider the following when making a determination about how (or if) research can be conducted on indicators potentially associated with a confirmed threat actor:

  • What is the level of confidence that the indicator or data is unique to a threat actor?
  • What is the level of confidence that the threat actor in question may discover the exposure given the type of research that is conducted?
  • Are there other mechanisms (mixing search terms, misspellings) that could be used to conduct research in a way that would reduce the likelihood of exposure of research?
  • What are alternate ways that the indicator could be discovered and researched that would not reveal KPMG’s awareness to the threat actor (i.e., making research appear to be a random bot, rather than directed)?

GSOC Analysts may become aware during the course of an investigation that an indicator is associated with an advanced threat actor only after some searches have been conducted.  In such a case, it should be handled as an accidental exposure (Section 5.1.2).

2.6             Blocked Security Site Research

In some cases, the GSOC will need to review or read security sites which are blocked by normal KPMG policy.  This this case, it is permissible to conduct such research, review, or reading using the Darkline.

2.7             Blocked Download

In some cases, the GSOC will need to download code, tools, or artefacts which are blocked by normal KPMG policy.  In this case, it is permissible to download the item using the Darkline.  After download, it is not permissible to move the code, download, or tool to the KPMG Corporate network without following normal processes for installation or use of new code on KPMG systems.

A blocked download via the Darkline may only be conducted by a L2 or Threat/Intel Analyst or higher-level individual.

2.8             Potential Malicious Site Research

During the course of a security incident investigation, it may be necessary to confirm whether a specific site was actually a malicious site, or attempt to get additional details about the site that can only be executed by actively browsing the site.

This category of access encompasses any of the following:

  • Any IP address, domain, or URL that has been identified as a potential C2, download, or exfiltration site of any type of malware, botnet, or exploit associated with a security incident.
  • A site associated with a criminal or threat actor that has the potential to be malicious or otherwise may attempt to attack, infiltrate, or otherwise track a KPMG Darkline system
  • The site, IP, domain, or URL is not associated with a TLP-Red or TLP-Amber indicator that could be associated with a targeted threat actor (details in section 3.5)

Access to potential malicious sites requires the use of a hardened system and must be previously approved by the L3 Analyst.  This research may only be conducted by a L2 or Threat/Intel Analyst or higher-level individual.

2.9             Malicious Site Honeyclient

During the course of a security incident investigation or during investigation of a known threat actor, it may be necessary to deliberately connect to a specific malicious site with a vulnerable client in order to get additional details about the site, exploit, or malware that can only be executed by actively connecting to the site with a vulnerable client.

This category of access encompasses any of the following:

  • Any IP address, domain, or URL that has been identified as a C2, download, or exfiltration site of any type of malware, botnet, or exploit associated with a security incident or ongoing threat intelligence investigation.
  • A site associated with a criminal or threat actor that has the potential to be malicious or otherwise may attempt to attack, infiltrate, or otherwise track a KPMG Darkline system
  • The site, IP, domain, or URL is not associated with a TLP-Red or TLP-Amber indicator that could be associated with a targeted threat actor (details in section 3.5)

Access to malicious sites for the purpose of running a honeyclient and deliberately allowing an exploit to run requires the use of a custom system designed and built for the purpose and must be previously approved by the L3 Analyst.  The methods and controls associated with use of the honeyclient may also require network or other restrictions approved by the L3 Analyst.  This research may only be conducted by a L2 or Threat/Intel Analyst or higher-level individual.

2.10        Interactive Internet security research

This form of research will only be conducted where there is no other option to gather this intelligence or information.  This form of research involves some form of long-term interactive access with a web-site, such as creation of a user account, acceptance of some form of terms to access a site, forum-posting, or IRC channel engagement.

Note:  This form of research does not encompass the enabling access to sites restricted by captchas – this is permitted to gain access to a site.

This research will only be conducted with L3 approval, may only be conducted by a L2 or Threat/Intel Analyst or higher-level individual, and may require additional controls or procedures requested by the L3 at the time of approval.

2.10.1      Persona management

An important considerations of this type of research is that there will need to be explicit personas created for each site, channel, or other interactive activity that KPMG analysts participate in.  Details and histories of these personas need to be careful tracked so that individuals using a persona as a part of research ensure that the persona remains consistent.

It is important to note that all personas will be used by KPMG GSOC Analysts during the course of their duties alone.  They are not owned by GSOC analysts, and are not to be used outside of authorized GSOC operations.

Persona information should include the following:

  • The specific site(s) and interfaces (IRC, forum) that the persona is approved for use
  • The mission/intent of the persona
  • Any restrictions on persona use imposed by the L3
  • Details of the persona authentication details (account name, password, challenge question/answer)
  • General background information about the personality and behaviour of the persona
  • Timeline of persona behaviour and usage
  • Details (times, screenshots, quotes) of specific interactions that the persona has had with external actors.

During the use of a persona, the GSOC analyst using it must pay careful attention for signs that the persona has inadvertently broken character, been exposed, or violated any restrictions.  In this case, the fact should be reported via the accidental exposure process (Section 5.1.2).

Some important considerations about usage of personas:

  • There is a risk of a “slippery slope” towards prohibited support of illegal activities.  As a persona engages with members of a forums/IRC channels suspected of use by cybercriminals, it is possible for a sense of rapport or connection to be built up with people the persona interact with.  There will be a temptation to help, or to build rapport by demonstrating knowledge of how to overcome a technical issue.  GSOC members using personas should always evaluate their persona communications to ensure that there is no perception of implied or actual support for illegal activities.
  • During the use of a persona, the GSOC members must continually communicate the patterns and details of their persona communications to the L3 Analyst, GSOC Operations Manager, or Head of the GSOC.  If at any point there is discomfort or concern about the actions of the persona or the communications that the persona receives, this should be immediately escalated.
  • If at any point a GSOC analyst is unable or unwilling to continue use of a persona, this request must be respected by his or her management, and the persona either discontinued or assigned to a different analyst.  Unwillingness to use a persona is not considered a failing or negative factor in any way.
  • If, during the use of a persona, the GSOC analyst believes there is evidence that a crime is about to occur or is ongoing, the GSOC analyst should immediately communicate this to the L3 Analyst, GSOC Operations Manager, and Head of the GSOC, and begin maintaining detailed notes of the interactions.  If there is a technical mechanism to maintain logs (screenshots, etc.,) of the evidence, this should be executed immediately. 

2.10.2      Limitations

Persona usage will always have limitations/bounds imposed by the L3 who approved its use.  Under no circumstances will a persona ever be used or participate in any illegal activity.

3                 Technology

There are various technology components which are used in support of the non-attribution process.  Each of them are used in support of different types of Internet access, but they are numerous controls common to all of them (detailed in Section 5 – Controls) which help ensure their safe use.

3.1             Darkline system

The most important technology component supporting non-attribution is the Darkline system.  The Darkline must offer several capabilities to meet minimum security controls for the GSOC:

  • Web-browsing on client systems must by default not maintain a browser history.  This may be modified for specific technology efforts as part of restrictions or requirements imposed by the L3.
  • Web client-systems must be fully patched prior to any web-access.  This will include patches for any third-party browser components (flash, java, silverlight) and plugins.
  • Third-party browser components of web client systems, including browser plugins, must be configured, if possible, to require user interaction for approval of executing any active content.
  • Web client-systems must not run as administrators, and Darkline users must not have permission to change/install Darkline components, including browser plugins.
  • Web client-systems must be configured to have a non-unique fingerprint (e.g., Panopticlick verification)
  • Web client-system must be re-imaged (or restarted from known-clean VM snapshot) at least every day, and after any access which is suspected to have caused issues or changes with the system.
  • The web-client system must have an ability to save/export downloads, screenshots, or web-content to a device which allows the KPMG GSOC to maintain data and records across reboots/reimages.
  • The firewall and/or transparent web-proxy (if any) associated with the Darkline must have the ability to log and/or capture web-connections from Darkline systems.

3.2             Darkline system with TOR activated

Under certain circumstances, the Darkline system may need to restrict web-browsing via TOR in order to increase the anonymity of its use.  The Darkline system with TOR must meet all of the above requirements for a normal Darkline system, plus the following restrictions:

  • Darkline systems with TOR must be separate images (or physical systems), with Layer 2/3 isolation from other Darkline systems (other than the firewall they use to connect to the Internet).
  • Darkline systems with TOR enabled must not allow non-TOR browsing or connections to the Internet.

3.3             Hardened Darkline system

The hardened Darkline system may be more than one type of system, to provide added flexibility for web-access and downloading.  Potential hardened Darkline systems include the following:

  • Custom, locked-down Windows build with no browser add-ons.
  • Custom, locked down Linux build with browser and limited browser add-ons.
  • Custom, locked down Linux build with text-based browsers (e.g., lynx, links) and web-access tools (e.g., wget, curl) only

Hardened Darkline systems must include all requirements for a normal Darkline systems, plus the following restrictions:

  • Hardened Darkline systems must be separate images (or physical systems), with Layer 2/3 isolation from other Darkline systems (other than the firewall they use to connect to the Internet).
  • Hardened Darkline systems must be reset/reimaged/restored to snapshot prior to every use.

4                 Controls

The below controls are intended to ensure that there is maximum tracking and accountability for Non-attributed access to the Internet.

4.1             Darkline acceptable use

The following guidelines apply to all users of the Darkline, in accordance with the Darkline policy.

4.1.1          Warning of controls and system identity

On the front of all darkline systems, there must be a physical reminder (such as a placard placed over the monitor, or over the keyboard) which reminds all users of the darkline system of the following:

  • Reminder of the core requirements of the Darkline policy
  • Reminder of what specific type of Darkline system they are using

If virtual machines are used on the darkline, the virtual machine names must clearly describe the type of virtual machine in use (i.e., Darkline, Darkline with TOR, etc.,) so that the users are clearly reminded of the type of system that they are using.  This naming scheme must not be visible within the Darkline system itself in case of compromise.

4.1.2          Careful browsing habits

Web-browsers often maintain some form of state when links are followed.  Darkline users must be careful to limit direct following of links (or use plugins which limit referrer information or other information) while using the Darkline.  This is intended to prevent web-sites which receive Darkline client-traffic from being able to see the reason or background of a connection to the site.

Examples of prohibited browsing habits include:

  • Directly clicking on search engine links that include either referrer or link redirectors.
  • Directly clicking on link shortcuts / link redirectors directly
  • Following links to new domains or sites and sending referrer information

4.1.3          No association with KPMG/Personal Identity

No element of the Darkline technology, user profiles, or other information on the Darkline systems can have any reference to KPMG or KPMG-associated persons.  Personal names are not allowed on any Darkline systems, and accounts cannot be associated with KPMG naming schemes or conventions.

Personnel using the Darkline systems may never browse to sites associated with them as individuals, or log into personal, KPMG, or other systems which have been accessed from non-Darkline systems.

An additional concern with Darkline systems is that items such as licenses, system serial numbers, and the like, could potentially be used to tie a darkline system to KPMG.  Darkline systems must use no software licenses, system serial numbers, or the like, which can be directly tied to KPMG.

4.1.4          Handling Accidental Exposures

There will be accidental exposures during the use of the Darkline.  These accidental exposures must be immediately reported to the L3 Analyst and the GSOC Operations Manager, along with all information/details that lead to the exposure.

An accidental exposure means that a GSOC member has discovered that one of the following criteria has been met:

  • A piece of information directly related to KPMG has been unintentionally posted or sent from a Darkline system.
  • A Darkline system user has unintentionally logged into a system or web-site using credentials not approved for Darkline use as part of a persona
  • A Darkline system user has unintentionally violated any other part of Darkline policy which may impact anonymity of the Darkline or the user.

When there is an accidental exposure, include the following information with the report:

  • The exact time and location (web-site/system name) of the exposure
  • The circumstances which led to the exposure
  • The identity of the specific Darkline system which was used to create the exposure
  • The browsing history of the Darkline system immediately before and after the exposure.
  • Any mitigating factors which may mitigate the result of the exposure.
  • An assessment of the likelihood that this exposure could result in exposure of the KPMG brand

GSOC Operations Manager will determine what follow-on actions need to be taken as a result of the exposure.  This will be in the form of a remediation plan, and optional reporting to senior leadership.

A checklist (more detailed) of steps to take in the event of violations will be reviewed/approved/maintained by the GSOC Operations Manager and a written copy of this checklist and plan maintained by the Darkline system.

4.1.5          Suspected Deliberate Violations

Suspected deliberate violations of this Non-attribution process, refusal to report an accidental exposure, or violations of the Darkline policy will be reported immediately, with information similar to what is required by the accidental exposure policy.  Deliberate violations must be escalated/reported immediately via voice/direct communication.

A checklist (more detailed) of steps to take in the event of violations will be reviewed/approved/maintained by the GSOC Operations Manager and a written copy of this checklist and plan maintained by the Darkline system.

4.1.6          Data removal from the Darkline

In the event that any data needs to be removed from the Darkline (logs, screenshots, downloads), the following requirements must be observed:

  • At least two people must inspect/observe the specific code or files being removed from the Darkline.
  • Removed items cannot be placed directly onto the KPMG internal network.  If needed, an off-line/standalone system can be used to modify the removed item (i.e., take a screenshot, migrate an excel spreadsheet to a CSV, save a PDF as text, etc.,) in a way that ensures that any data taken to the KPMG network is in text format, or screenshot from the standalone system.
  • The mechanism used to remove/store data taken from the Darkline must be labelled and used only for the purpose of Darkline data migration, and be large enough (i.e., large external hard-drive) that it cannot be easily or accidentally removed from the environment.

4.2             Darkline Analyst Log

All GSOC Analysts using the Darkline must maintain a summarized log of activity they take on the Darkline.  This summarized log will be a manual (written) log which must include the following entries at a minimum:

  • Start/stop of use of Darkline
  • Specific reason for use of Darkline (i.e., research incident XXXXX)
  • If higher-level approval was required, a list of limitations for the actions, and the identity of the approver.
  • Summary of sites visited (doesn’t have to be all inclusive)
  • Any issues encountered

This log is not intended to be time-consuming or exhaustive, but simply to ensure that there’s a traceable tie to business necessity for all Darkline usage.  This written log must be maintained in perpetuity.

In the event of a request by law enforcement, regulators, or internal audit for review of activities conducted by the GSOC, these records must be turned over and maintained.

4.3             Darkline Automated Logging

In addition to Analyst (manual) logs, the Darkline infrastructure should attempt (best effort) to maintain records of the following for at least 1 year.  This logging should be maintained in a format which reduces the risk of accidental or deliberate destruction or modification (i.e., WORM drives, or external log server)

Desired automated logging:

  • Darkline system reboots
  • Darkline system logins/logouts
  • Darkline system connections to the Internet (with URL information if possible)

In the event of a request by law enforcement, regulators, or internal audit for review of activities conducted by the GSOC, these records must be turned over and maintained.

4.4             L3 Approval

Multiple different types of Non-attributed browsing may require review and approval of the L3.  The L3 is intended to make technical and threat-based assessments to drive their decision-making, and create restrictions or limitations on use as needed to minimize risk to KPMG.

4.4.1          General Guidance

In general, the purpose of the L3 review is solely for the purpose of minimizing risk to the KPMG brand, while still allowing the GSOC to take advantage of the non-attributed research capability of the Darkline.  Secondary purposes of the L3 review include the need to ensure that there is oversight of the Darkline, and to ensure that potentially high-risk activities require some form of discussion or consideration prior to execution.

The L3 is expected to escalate to the GSOC Operations Manager and/or GSOC Director if there is any reason that he/she believes that the risk is too high, or that an additional authority or scrutiny would be valuable to reduce risk or enable the activity to be more effective.

4.4.2          Limitations

When the L3 approves some form of Non-attributed browsing to achieve a research goal, it is expected that the approval will come with some form of limitations to mitigate risk and exposure of the activity.  Some examples of potential limitations include:

  • Restricting the activity to specific, named sites
  • Bounding the activity by length of time, time of day, or number of sites
  • Requiring additional technical controls (browser plugins)
  • Prescribing specific browsing behaviour
  • Requiring 2-person involvement for some activities.

4.4.3          Potential requirement for Legal Review

The L3 Analyst is not allowed to authorize activities which could potentially be illegal or in violation of a terms of use (i.e., web-site click-through terms and condition agreement), without some form of legal review.  This is a clear requirement for escalation to the Operations Manager.

4.5             Potential Additional Controls

In the event that the GSOC is conducting research on behalf of a third-party (other KPMG organization, clients), it may be that additional controls or limitations will be applied to the research being conducted by GSOC analysts.  In this case, guidance for the additional research will be provided by the GSOC Operations Manager to all analysts prior to execution of such research.

  1. Constraints and Assumptions

·     Background

The purpose of this appendix is to describe significant constraints and assumptions that are the key drivers for the design and content of this process.  The purpose of identifying these key constraints and assumptions is to ensure that when constraints change or assumptions are disproven, that the processes are examined to ensure that they still apply and are optimized for the goals of the GSOC.

4.6             Available Technology

This process is entirely dependent on, and expects the availability of specific technology:

  • VDI/Remote Desktop infrastructure for GSOC
  • Exceptions to allow the use of security-related plugins on browsers
  • GSOC Darkline system which includes
    • Virtualized endpoints
    • An option for hardened endpoints
    • A logging facility

4.7             Protection of KPMG brand as the priority

This process is designed primarily to reduce risk to the KPMG brand, both by removing the association of KPMG-owned IP space with security research activities and reducing the likelihood of a compromise of KPMG-systems due to browsing/access to GSOC research activities.

4.8             Acceptance of some degree of risk

The Non-attribution policy is flexible enough to allow GSOC analysts to conduct research across the Internet, with limited corporate security controls.  This decision enhances GSOC capabilities, but does create risk.