REVIEW: “The Social Life of Information”, John Seely Brown/Paul Duguid

BKSCLFIN.RVW   20130124

“The Social Life of Information”, John Seely Brown/Paul Duguid, 2000,
0-87584-762-5, U$24.95
%A   John Seely Brown
%A   Paul Duguid
%C   60 Harvard Way, Boston MA   02163
%D   2000
%G   0-87584-762-5
%I   Harvard Business School Press
%O   U$25.95 617-495-6947 617-495-6700 617-495-6117 800-545-7685
%O  http://www.amazon.com/exec/obidos/ASIN/0875847625/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0875847625/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0875847625/robsladesin03-20
%O   Audience n+ Tech 2 Writing 2 (see revfaq.htm for explanation)
%P   320 p.
%T   “The Social Life of Information”

The introduction is vague, but basically notes that those who approach information in a strictly technical or business sense risk failure by ignoring the social context in which information resides.  Information does not exist of itself, but is produced and consumed by people, and thus is a construct and artifact of our social environment.

Chapter one talks about information overload.  Bots are discussed in chapter two: not the botnets (simple programs distributed over multiple computers) that everyone agrees should be eliminated, but the range of software agents that we use without thinking.  The authors note that the interactions between these bots are inherently impossible to control, and the material prophecies the recent problems in content blocking such as affected the Hugo awards and Michelle Obama.  Chapter three examines various social issues of home (or non-office) -based work.  The difference between our processes, and the way people actually work, are addressed in chapter four.  A number of interesting ideas are raised, but it is (ironically) difficult to see how to put these into practice (rather than discussion of what we should do).  Chapter five turns to learning and knowledge management.  The authors assert that learning is primarily social, and note negative effects on business if this aspect is ignored, but actually say very little about learning or information.  Chapter six explores innovation in respect to the Internet and a global economy, noting that information is difficult to control in that it is both “sticky” (resistant to change) and “leaky” (incidental disclosures of “confidential” information abound).  The “background” of information is noted in chapter seven, with the authors examining the resilience of paper in the face of a determined effort to create the “paperless” office.  They note studies showing that “printing” out email seemed to automatically give the data greater weight.  (I wonder if this might have changed in today’s marketplace: sadly, a rather large proportion of people now seem to hold that *anything* found on the Internet, regardless of how silly, must be true.)  Chapter eight, entitled “Re-education,” discusses the changing nature of universities.

There is an afterword, “Beyond Information,” touching on miscellaneous points, particularly to do with copyright.

Despite a certain lack of structure or purpose to some of the sections, the writing is both clear and entertaining.  It also has that ineffable quality of readability, meaning that the reading is enjoyable even when the authors are not delivering specifically interesting information, or making a vital point in an argument.  It’s a joy simply to consume the text.

copyright, Robert M. Slade   2013   BKSCLFIN.RVW   20130124

Developing an IR Process and Team

In our world today, we have an abundance of many things, among which are –unexpected events. Falling meteorites, terrorist attacks, hacktivist demonstrations, blackouts, tsunamis…. well, you get the point.Now, although the majority of events I just mentioned probably fall into a Disaster Recovery category, they are nonetheless events that greatly impact our personal lives and disrupt the normal ebb and flow of the daily routine.On the professional side of life, there are also incidents that,although classified on a lower scale than a disaster, still create much disruption and depending on how they are handled, can have a long-lasting impact to the flow of business. The purpose of this article is to discuss some suggested methods of how to go about building an incident response team and related procedures that will enable this group to respond to these events expeditiously.

TERMINOLOGY DEFINED

Before we start to discuss the mechanics behind building this elite group of technical emergency responders, let’s understand what we’re up against. First of all, let’s get our terminology straight. What exactly am I referring to when I use the term – “event” and “incident“? To give this article some context, consider the following definitions courtesy of Merriam Webster…

  • An incident is defined as “an occurrence […] that is a separate unit of experience”.
  • An event can be defined as “something that happens: an occurrence” or “a noteworthy happening”.

Let’s break this down;if we use the example of a small electrical fire in the basement of a building, this can be categorized as an individual “incident” or as a “separate unit of experience”. Now, if this incident is not handled properly, it can escalate and possibly grow to become a fire so large that it consumes the entire building. The incineration of the building can be categorized as an “event“, which is sort of an umbrella term that groups causes and effects for the entire disaster or “noteworthy happening” into one category.

Applying this understanding to the enterprise, items such as a data breaches, hacking attempts, critical server crashes, website defacement or social engineering attempts can be classified as individual “incidents”. This is because they may affect business or the corporate reputation but may not completely halt the business flow of the company. If not addressed properly, these incidents,although small,could escalate and succeed in completely halting the business,resulting in a disaster or large scale “event“. Hopefully, this explanation clarifies the difference between events and incidents as this understanding will determine how each occurrence is handled. This now brings us to our next section…

PLANNING AN INCIDENT RESPONSE PROCESS

This step can seem daunting if you’ve never been involved with Incident Response or you’re trying to decide where a process like this might fit in to your particular environment. How can we go about organizing all the related business groups, technical areas and how can we find out if we’re missing anything?The good news is that in the majority of cases, there is already some type of set process that is followed whenever incidents occur. Some problems that come up, however, could be that the process may not be documented and since it’s an informal process, there is a great chance that core response components are missing or have been overlooked. The benefit to identifying any existing process that your organization may have is that it is much easier to train employees using a foundation with which they are already accustomed to. It may also be much easier to gain upper management’s support and buy-in for a process that is actively being followed albeit – informally.This support is necessary because management’s support will be needed for any funding that is required and for the allocation of time for the individuals that will be forming part of the official team. Without this support, it’s possible that your project will never get off its feet or after all the hard work,the process could be scrapped or drastically changed and then it’s back to the proverbial drawing board. This can beextremely frustrating so be sure to do your homework, identify any area that may already be built and if appropriate, incorporate this into your draft IR process.This way you’ll have a deep understanding of how the process should flow when having discussions with upper management and be able to defend any modifications, enhancements or complete overhauls.

Keep in mind that when speaking with management, your initial draft is just that – a draft. Be prepared to have a detailed conversation so you can understand what their expectations are and that you properly define what your incident process is providing. It’s possible that in these initial conversations you will identify areas that need to be modified or added.If this step is not accomplished correctly,it’s possible that the functions of your future IR team will not be understood or properly recognized.This could result in your process not being properly advertised to the enterprise, in which case it simply becomes just another “informal process”. Be sure to gain managements approval, communicate and advertise your new structure so that when an incident does occur, your new framework will be used.This will eliminate any overlap and ensure that the authority of the members of your future IR team remains fully recognized.

Some other questions that you may ponder along the way:

  • How far will IR processes be able to reach?
  • Who will make up the IR Team’s client base?

The first question relating to the reach of the IR process speaks to cases where critical services and applications are provided by external third parties. In these cases, you will have to decide on how far the IR process will flow and if a “hand-off” needs to occur. This needs to be explored at length since this will make your resolution process dependent on the efforts of an outside entity.

Questions like these are highly important because in the case of many enterprise environments, there are multiple areas that are critical to business operations. This brings us to the second question regarding the IR client base. This refers to subsidiaries or operating companies that, although separate, may fall under the auspices of the parent organization. You need to understand the relationship to these companies and if they provide critical applications, services and other related business functions. More than likely, these entities will also have to fall under the scope of your IR process and it will be necessary to identify key stakeholders at those locations to support your IR. This begs the question… who should form part of the Incident Response team?

INCIDENT RESPONSE ROLES AND RESPONSIBILITIES

Depending on what you read, you may find different titles and roles for Incident Response. The following listing is an outline of some roles and responsibilities that I used when building an IR plan at a past employer. Each environment is unique, so you will need to research your own requirements and then tailor a plan that meets your needs. Generally, the types of roles that should exist within an IR function are:

Incident Response Officer – This individual is the Incident Response champion that has ultimate accountability for the actions of the IR team and IR function. This person should be an executive level employee such as a CISO or other such corporate representatives. It would be very beneficial if this individual has direct reporting access to the CEO and is a peer of other C-level executives.

Incident Response Manager – This person is the individual that leads the efforts of the IR team and coordinates activities between all of its respective groups. Normally, this person would receive initial IR alerts and be responsible for activating the IR team and managing all parts of the IR process, from discovery, assessment, remediation and finally resolution. This individual reports to the Incident Response Officer.

Incident Response Assessment Team – This group of individuals is composed of the different areas serviced by the IR team. This allows expertise from every critical discipline to weigh in on classifications and severity decisions once an incident has been identified. It is very beneficial to have representatives from IT, Security, Application Support and other business areas. In the event of an incident, the IR Manager would gather details of the incident from the affected site, begin tracking and documentation (possibly through an internal ticket management system) and then activate the Assessment Team. This group would then discuss the details of the incident and based on their expertise and knowledge of the business, would then be able to assign an initial severity. This team reports to the IR Manager.

Remote Incident Response Coordinator – This role should be assigned to qualified and capable individuals that are located in other geographic areas. These individuals ultimately report to the Incident Response Manager but in their geographic region, they are recognized as IR leaders. This will allow these assistants to manage the efforts of local custodians during an incident. This configuration is very useful, especially for organizations that have offices in multiple time zones. If an IR Manager is located in the United States but an incident occurs in a Malaysian branch, it will be helpful to have a local security leader that is able to direct efforts and provide status updates to the Incident Manager. This way, regardless of the time zone the correct actions will be invoked promptly.

Incident Response Custodians – These individuals are the technical experts and application support representatives that would be called upon to assist in the remediation and resolution of a given incident. They report to the Incident Response Manager or to the Remote IR Coordinator(s) depending on their location(s).

Once you’ve been able to identify the proper stakeholders that will form your team, you will have to provide an action framework they’ll be able to use when carrying out their responsibilities. Think of this “action framework” as a set of training wheels that will guide your IR team. What does this mean? Let’s move on to the next section to discuss this…

INCIDENT RESPONSE PROCESS FLOW

A part of outlining this framework involves the identification of IR Severity Levels. These levels will help your team understand the severity of an event and will govern the team’s response. Some suggestions for these levels are the following:

SEVERITY LEVEL LEVEL OF BUSINESS IMPACT RESOLUTION EFFORT REQUIRED
SEVERITY 1 LOW LOW EFFORT
SEVERITY 2 MODERATE MODERATE EFFORT
SEVERITY 3 HIGH EXTENSIVE, ONGOING EFFORT
SEVERITY 4 SEVERE DISASTER RECOVERY INVOKED

Earlier in this article, I mentioned the benefit of identifying any existing informal process that your company may already be following. If so, it will now be necessary for you to step through that process mentally, keeping in mind your identified severity levels so that you can start to document each step of the process. You will undoubtedly start to remove irrelevant portions of the informal process but may opt to keep certain items in place. (For example, certain notification procedures may still be useful and you may continue to use these in your new IR process to alert members of your team). If you don’t have a starting point like this and you’re starting from scratch, then perhaps the following suggestions can provide some direction.

Start to create a documented action script that will outline your response steps so your IR Manager can follow them consistently. Your script should show steps similar to the following:

STEP # ACTION
1 Incident announced
2 IR Manager alerted
3 IR Manager begins information gathering from affected site
4 IR Manager begins tracking and documentation of incident
5 IR Manager invokes Assessment Team
(Details of call bridge or other communication mechanism)
6 Assessment Team reviews details and decides on Severity Level of incident.
7 IF SEV 1 = PROCEED TO STEP #11.0
8 IF SEV 2 = PROCEED TO STEP #12.0
9 IF SEV 3 = PROCEED TO STEP #13.0
10 IF SEV 4 = PROCEED TO STEP #14.0
FOR SEVERITY LEVEL 1 – Proceed with following sequence
11.0 Determine attack vectors being used by threat
11.1 Determine network locations that are impacted
11.2 Identify areas that fall under “Parent Organization”
11.3 Identify systems or applications that are impacted
FOR SEVERITY LEVEL 2 – Proceed with following sequence
12.0 Determine attack vectors being used by threat
12.1 Alert Incident Officer to Severity 2 threat

This of course is an extremely high level example, but as you can see, it is possible to flesh out the majority of the process with specific action items for each severity level. Be sure to thoroughly research your unique environment to develop a process that fits your needs. You may have to add custom steps to cover incidents that span multiple countries and subsidiaries. Once you’ve created your process.you may want to consider developing small wallet size scripts for the members of your Assessment Team and other key players on which you will need to depend to make this run efficiently. In this way, each member will have necessary information on hand that will allow them to respond as expected.

This article just scratches the surface of the work that is required to build a full IR process but hopefully this has given you some direction and additional areas to explore when planning your next IR project!

References:

Windows 2012 R2 Certification Authority installation guide

This step-by-step guide explains how to install and configure public key infrastructure, based on:

  • Windows 2012 R2 Server core – offline Root CA
  • Windows 2012 R2 domain controller
  • Windows 2012 R2 standard edition – Subordinate Enterprise CA server

Offline Root CA – OS installation phase

  1. Boot the server using Windows 2012 R2 bootable DVD.
  2. From the installation option, choose “Windows Server 2012 R2 Standard (Server Core Installation)” -> click Next.
  3. Accept the license agreement -> click Next.
  4. Choose “Custom: Install Windows Only (Advanced)” installation type -> specify the hard drive to install the operating system -> click Next.
  5. Allow the installation phase to continue and restart the server automatically.
  6. To login to the server for the first time, press CTRL+ALT+DELETE
  7. Choose “Administrator” account -> click OK to replace the account password -> specify complex password and confirm it -> press Enter -> Press OK.
  8. From the command prompt window, run the command bellow:
    sconfig.cmd
  9. Press “2” to replace the computer name -> specify new computer name -> click “Yes” to restart the server.
  10. To login to the server, press CTRL+ALT+DELETE -> specify the “Administrator” account credentials.
  11. From the command prompt window, run the command bellow:
    sconfig.cmd
  12. Press “5” to configure “Windows Update Settings” -> select “A” for automatic -> click OK.
  13. Press “6” to download and install Windows Updates -> choose “A” to search for all updates -> Choose “A” to download and install all updates -> click “Yes” to restart the server.
  14. To login to the server, press CTRL+ALT+DELETE -> specify the “Administrator” account credentials.
  15. From the command prompt window, run the command bellow:
    sconfig.cmd
  16. In-case you need to use RDP to access and manage the server, press “7” to enable “Remote Desktop” -> choose “E” to enable -> choose either “1” or “2” according to your client settings -> Press OK.
  17. Press “8” to configure “Network settings” -> select the network adapter by its Index number -> press “1” to configure the IP settings -> choose “S” for static IP address -> specify the IP address, subnet mask and default gateway -> press “2” to configure the DNS servers -> click OK -> press “4” to return to the main menu.
  18. Press “9” to configure “Date and Time” -> choose the correct “date/time” and “time zone” -> click OK
  19. Press “11” to restart the server to make sure all settings take effect -> click “Yes” to restart the server.
  20. 20. To login to the server, press CTRL+ALT+DELETE -> specify the “Administrator” account credentials.
  21. From the command prompt window, run the command bellow:
    powershell
  22. Run the commands bellow to enable remote management of the Root CA:
    Enable-NetFirewallRule -DisplayGroup "Remote Service Management"
    Note: The above command should be written in single line.
    Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Offline Root CA – Certificate Authority server installation phase

  1. To login to the server, press CTRL+ALT+DELETE -> specify the “Administrator” account credentials.
  2. From the command prompt window, run the command bellow:
    powershell
  3. Run the command below to create CA policy file:
    notepad c:\windows\capolicy.inf
  4. Specify the following data inside the capolicy.inf file:
    [Version]
    Signature="$Windows NT$"
    [Certsrv_Server]
    RenewalKeyLength=4096
    RenewalValidityPeriod=Years
    RenewalValidityPeriodUnits=20
    CRLPeriod=Weeks
    CRLPeriodUnits=26
    CRLDeltaPeriod=Days
    CRLDeltaPeriodUnits=0
    LoadDefaultTemplates=0
    AlternateSignatureAlgorithm=1
    [PolicyStatementExtension]
    Policies=LegalPolicy
    [LegalPolicy]
    OID=1.2.3.4.1455.67.89.5
    Notice="Legal Policy Statement"
    URL=http://www/CertEnroll/cps.asp
  5. Run the commands below to install Certification Authority using Powershell:
    Import-Module ServerManagerAdd-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools
    Note: The above command should be written in single line.
  6. Run the command below to install the Root CA:
    Install-AdcsCertificationAuthority -CAType StandaloneRootCA -KeyLength 4096 -HashAlgorithmName SHA256 -ValidityPeriod Years -ValidityPeriodUnits 20 -CACommonName <CA_Server_Name> -CryptoProviderName "RSA#Microsoft Software Key Storage Provider"
    Note 1: The above command should be written in single line.
    Note 2: Replace “CA_Server_Name” with the Root CA NetBIOS name.
  7. Run the command below to remove all default CRL Distribution Point (CDP):
    $crllist = Get-CACrlDistributionPoint; foreach ($crl in $crllist) {Remove-CACrlDistributionPoint $crl.uri -Force};
    Note: The above command should be written in single line.
  8. Run the commands below to configure new CRL Distribution Point (CDP):
    Add-CACRLDistributionPoint -Uri C:\Windows\System32\CertSrv\CertEnroll\%3%8.crl -PublishToServer -Force
    Note: The above command should be written in single line.
    Add-CACRLDistributionPoint -Uri http://www/CertEnroll/%3%8.crl -AddToCertificateCDP -Force
    Note: The above command should be written in single line.
  9. Run the command below to remove all default Authority Information Access (AIA):
    $aialist = Get-CAAuthorityInformationAccess; foreach ($aia in $aialist) {Remove-CAAuthorityInformationAccess $aia.uri -Force};Note: The above command should be written in single line.
  10. Run the command below to configure new Authority Information Access (AIA):
    Add-CAAuthorityInformationAccess -AddToCertificateAia -uri http://www/CertEnroll/%1_%3.crt
    Note: The above command should be written in single line.
  11. Run the commands below to configure the Root CA settings:
    certutil.exe -setreg CA\CRLPeriodUnits 26
    certutil.exe -setreg CA\CRLPeriod "Weeks"
    certutil.exe -setreg CA\CRLDeltaPeriodUnits 0
    certutil.exe -setreg CA\CRLDeltaPeriod "Days"
    certutil.exe -setreg CA\CRLOverlapPeriodUnits 12
    certutil.exe -setreg CA\CRLOverlapPeriod "Hours"
    certutil.exe -setreg CA\ValidityPeriodUnits 20
    certutil.exe -setreg CA\ValidityPeriod "Years"
    certutil.exe -setreg CA\KeySize 4096
    certutil.exe -setreg CA\AuditFilter 127
  12. Run the commands bellow from command line, to configure the Offline Root CA to publish in the active-directory:
    certutil.exe -setreg ca\DSConfigDN "CN=Configuration, DC=mycompany,DC=com"
    Note 1: The above command should be written in single line.
    Note 2: Replace “DC=mycompany,DC=com” according to your domain name.
    certutil.exe -setreg ca\DSDomainDN "DC=mycompany,DC=com"
    Note: Replace “DC=mycompany,DC=com” according to your domain name.
  13. Run the command bellow to stop the CertSvc service:
    Restart-Service certsvc
  14. Run the command below to publish new CRL’s:
    certutil.exe -CRL

Enterprise Subordinate CA – OS installation phase
Pre-requirements:

  • Active Directory (Forest functional level – Windows 2012 R2)
  • Add “A” record for the Root CA to the Active Directory DNS.
  1. Boot the server using Windows 2012 R2 bootable DVD.
  2. From the installation option, choose “Windows Server 2012 R2 Standard (Server with a GUI)” -> click Next.
  3. Accept the license agreement -> click Next.
  4. Choose “Custom: Install Windows Only (Advanced)” installation type -> specify the hard drive to install the operating system -> click Next.
  5. Allow the installation phase to continue and restart the server automatically.
  6. To login to the server for the first time, press CTRL+ALT+DELETE
  7. Choose “Administrator” account -> click OK to replace the account password -> specify complex password and confirm it -> press Enter -> Press OK.
  8. From the “Welcome to Server Manager”, click on “Configure this local server” -> replace the “Computer name” -> restart the server.
  9. From the “Welcome to Server Manager”, click on “Configure this local server” -> click on Ethernet -> right click on the network interface -> properties -> configure static IP address.
  10. Enable “Remote Desktop”
  11. From the command prompt window, run the command bellow:
    powershell
  12. Run the commands bellow to enable remote management of the Root CA:
    Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Enterprise Subordinate CA – Certificate Authority server installation phase
Pre-requirements:

  • DNS CNAME record named “www” for the Enterprise Subordinate CA.
  • Make sure the clocks of the Offline Root CA and the Subordinate CA are synched.
  1. To login to the server, press CTRL+ALT+DELETE -> specify the credentials of account member of “Schema Admins”, “Enterprise Admins” and “Domain Admins”.
  2. Copy the files bellow from the Offline Root CA server to a temporary folder on the subordinate CA:
    C:\Windows\System32\CertSrv\CertEnroll\*.crt
    C:\Windows\System32\CertSrv\CertEnroll\*.crl
  3. Run the command below to publish the Root CA in the Active Directory:
    certutil.exe -dspublish -f "<CACertFileName.crt>" RootCA
    Note: Replace “CACertFileName” with the actual CRT file.
  4. Run the commands below to add the Root CA certificate to the subordinate CA certificate store:
    certutil.exe -addstore -f root "<CACertFileName.crt>"
    certutil.exe -addstore -f root "<CACertFileName.crl>"

    Note: Replace “CACertFileName” with the actual CRT and CRL files.
  5. From the command prompt window, run the command bellow:
    powershell
  6. Run the command below to create CA policy file:
    notepad c:\windows\capolicy.inf
  7. Specify the following data inside the capolicy.inf file:
    [Version]
    Signature="$Windows NT$"
    [Certsrv_Server]
    RenewalKeyLength=2048
    RenewalValidityPeriod=Years
    RenewalValidityPeriodUnits=5
    LoadDefaultTemplates=0
    AlternateSignatureAlgorithm=1
  8. Run the commands below to install Certification Authority using Powershell:
    Import-Module ServerManagerAdd-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools
    Note: The above command should be written in single line.
    Add-WindowsFeature Web-Mgmt-Console
    Add-WindowsFeature Adcs-Web-Enrollment
  9. Open Server Manager -> From the “Welcome to Server Manager”, click on notification icon -> click on “Configure Active Directory Certificate Services on the destination server”
  10. Specify credentials and click on Next.
  11. Select both “Certification Authority” and “Certification Authority Web Enrollment” roles and click on Next.
  12. Select “Enterprise CA” -> click on Next.
  13. Select “Subordinate CA” -> click on Next.
  14. Select “Create a new private key” -> click on Next.
  15. Cryptography:
    Cryptographic service provider (CSP): RSA#Microsoft software Key Storage Provider
    Key length: 2048
    Hash algorithm: SHA256
  16. CA Name:
    Common name: specify here the subordinate server NetBIOS name
    Distinguished name suffix: leave the default domain settings
  17. Select “Save a certificate request to file on the target machine” -> click Next
  18. Specify the database location and click Next.
  19. Click on Configure -> wait until the process completes and click on Close.
    Note: If asked, choose not to configure additional role services.
  20. Copy the request file (*.req) to the Offline Root CA.
  21. Login to the Offline Root CA using administrative account.
  22. Run the command below to approve the subordinate CA certificate request:
    certreq -submit "<CACertFileName>.req"
    Note: Replace “CACertFileName” with the actual request file.
  23. Run the command below to approve the subordinate CA request:
    certutil -resubmit 2
    Note: Replace “2” with the request ID.
  24. Run the command below to command to download the new certificate.
    certreq -retrieve 2 "C:\<CACertFileName>.cer"
    Note 1: Replace “CACertFileName” with the actual CER file.
    Note 2: Replace “2” with the request ID.
  25. Logoff the Root CA and power it off for up to 179 days (for CRL update).
  26. Return to the Subordinate CA.
  27. Copy the file “c:\<CACertFileName>.cer” from the Offline Root CA to the Subordinate CA.
    Note: Replace “CACertFileName” with the actual CER file.
  28. Run the commands below to complete the Subordinate CA installation process:
    powershell
    Certutil -installcert "<CACertFileName>.cer"

    Note: Replace “CACertFileName” with the actual CER file.
  29. Run the command below to restart the CA service:
    start-service certsvc
  30. Run the command below to remove all default CRL Distribution Point (CDP):
    $crllist = Get-CACrlDistributionPoint; foreach ($crl in $crllist) {Remove-CACrlDistributionPoint $crl.uri -Force};
    Note: The above command should be written in single line.
  31. Run the commands below to configure new CRL Distribution Point (CDP):
    Add-CACRLDistributionPoint -Uri C:\Windows\System32\CertSrv\CertEnroll\%3%8%9.crl -PublishToServer -PublishDeltaToServer -Force
    Note: The above command should be written in single line.
    Add-CACRLDistributionPoint -Uri http://www/CertEnroll/%3%8%9.crl -AddToCertificateCDP -Force
    Note: The above command should be written in single line.
    Add-CACRLDistributionPoint -Uri file://\\<SubordinateCA_DNS_Name>\CertEnroll\%3%8%9.crl -PublishToServer -PublishDeltaToServer -Force
    Note 1: The above command should be written in single line.
    Note 2: Replace “<SubordinateCA_DNS_Name>” with the actual Subordinate CA DNS name.
  32. Run the command below to remove all default Authority Information Access (AIA):
    $aialist = Get-CAAuthorityInformationAccess; foreach ($aia in $aialist) {Remove-CAAuthorityInformationAccess $aia.uri -Force};
    Note: The above command should be written in single line.
  33. Run the commands below to configure new Authority Information Access (AIA):
    Add-CAAuthorityInformationAccess -AddToCertificateAia http://www/CertEnroll/%1_%3%4.crt -Force
    Note: The above command should be written in single line.
    Add-CAAuthorityInformationAccess -AddToCertificateAia "ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11"Note: The above command should be written in single line.
    Add-CAAuthorityInformationAccess -AddToCertificateOcsp http://www/ocsp -Force
    Note: The above command should be written in single line.
  34. Run the commands below to configure the Root CA settings:
    Certutil -setreg CA\CRLPeriodUnits 2
    Certutil -setreg CA\CRLPeriod "Weeks"
    Certutil -setreg CA\CRLDeltaPeriodUnits 1
    Certutil -setreg CA\CRLDeltaPeriod "Days"
    Certutil -setreg CA\CRLOverlapPeriodUnits 12
    Certutil -setreg CA\CRLOverlapPeriod "Hours"
    Certutil -setreg CA\ValidityPeriodUnits 5
    Certutil -setreg CA\ValidityPeriod "Years"
    certutil -setreg CA\AuditFilter 127
    certutil -setreg CA\EncryptionCSP\CNGEncryptionAlgorithm AES
    certutil -setreg CA\EncryptionCSP\SymmetricKeySize 256
    certutil -setreg CA\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE
    certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
    Note: The above command should be written in single line.
  35. Run the command bellow to stop the CertSvc service:
    Restart-Service certsvc
  36. Run the command below to public new CRL’s:
    certutil.exe -CRL
  37. Copy the files bellow from the Root CA to the subordinate CA (same location):
    C:\Windows\System32\CertSrv\CertEnroll\*.crl
    C:\Windows\System32\CertSrv\CertEnroll\*.crt
  38. Create CPS (Certificate Practice Statement), save it as “cps.asp” inside the subordinate CA under the folder below:
    C:\Windows\System32\CertSrv\CertEnroll
    Note: For more information about Certificate Practice Statement, see:
    http://technet.microsoft.com/en-us/library/cc780454(v=ws.10).aspx
  39. Login to a domain controller in the forest root domain, with account member of Domain Admins and Enterprise Admins.
  40. Open Server Manager -> Tools -> Active Directory Users and Computers.
  41. From the left pane, expand the domain name -> choose an OU and create the following groups:
    Group name: CA Admins
    Group description/purpose: Manage CA server
    Group name:
    CA Issuers
    Group description/purpose: Issue certificates
  42. Logoff the domain controller.
  43. Login to the Subordinate CA using administrative account, who is also member of the “CA Admins” group.
  44. Open Server Manager -> Tools -> Certification Authority.
  45. From the left pane, right click on the CA server name -> Properties -> Security tab -> Add -> add the “CA Admins” group -> grant the permissions “Issue and Manage Certificates” and “Manage CA” and remove all other permissions -> click on OK.
    Note: As best practices, it is recommended to remove the default permissions of “Domain Admins” and “Enterprise Admins”.
  46. From the left pane, expand the CA server name -> right click on Certificate Templates -> Manage -> from the main pane, right click on “User” certificate -> Duplicate Template -> General tab -> rename the template to “Custom User Certificate” -> Security tab -> click on Add -> add the “CA Issuers” group -> grant the permission “Read”, “Enroll” and “Autoenroll” -> click on OK.
  47. From the main pane, right click on “Web Server” certificate -> Duplicate Template -> General tab -> rename the template to “Custom Web Server Certificate” -> Request Handling tab -> select “Allow private key to be exported” -> Security tab -> click on Add -> add the “CA Issuers” group -> grant the permission “Read” and “Enroll” -> remove the permissions for the built-in Administrator account -> click on OK.
    Note: All computer accounts requesting the “Custom Web Server Certificate” certificate must be member of the “CA Issuers” group.
  48. From the main pane, right click on “OCSP Response Signing” certificate -> Duplicate Template -> General tab -> rename the template to “Custom OCSP Response Signing” -> Security tab -> add the subordinate CA computer account -> grant “Read”, “Enroll” and “Autoenroll” -> click OK.
  49. From the main pane, right click on “Web Server” certificate -> Properties -> Security tab -> click on Add -> add the “CA Issuers” group -> grant the permission “Read” and “Enroll” -> click OK
  50. Close the Certificate Templates Console.
  51. From the Certification Authority console left pane, right click on Certificate Templates -> New -> Certificate Template to issue -> select the following certificate templates:
    Web Server
    Custom User Certificate
    Custom Web Server Certificate
    Custom OCSP Response Signing
  52. Click OK.
  53. Close the Certification Authority console.
  54. Open Server Manager -> Manage -> Add Roles and Features -> click Next 3 times -> expand “Active Directory Certificate Services” -> select “Online Responder” -> click on Add Features -> click Next twice -> click on Install -> click on Close
  55. From the upper pane, click on notification icon -> click on “Configure Active Directory Certificate Services on the destination server”
  56. Specify credentials and click on Next.
  57. Select “Online Responder” -> click Next -> click on Configure -> click Close.
  58. From the left pane, right click on “Online Responder” -> Responder Properties -> Audit tab -> select “Changes to the Online Responder configuration”, “Changes to the Online Responder security settings” and “Requests submitted to the Online Responder” -> click OK -> close the “Online Responder Configuration” console.
  59. Open Server Manager -> Tools -> Local Security Policy -> from the left pane, expand “Advanced Audit Policies” -> expand “System Audit Policies – Local Group Policy Object” -> click on Object Access -> from the main pane, double click on “Audit Certification Services” -> select “Configure the following audit events” -> select both Success and Failure -> click OK -> close the Local Security policy console.
  60. Run from command line:
    certutil -CRL
  61. Run from command line:
    certutil -v -setreg policy\editflags +EDITF_ENABLEOCSPREVNOCHECK
    Note: The above command should be written in single line.
  62. Run the commands bellow to stop the CertSvc service:
    powershell
    Restart-Service certsvc
  63. Open Server Manager -> Tools -> Online Responder Management
  64. From the left pane, right click on “Revocation Configuration” -> Add revocation configuration -> click Next -> on the name field, specify “Custom Revocation Configuration” -> click Next -> select “Select a certificate for an Existing enterprise CA” -> click Next -> click Browse -> select the subordinate CA -> click OK -> Automatically select a signing certificate -> click Next -> click Finish
  65. Close the Online Responder Management console
  66. Login to a domain controller in the forest root domain, with account member of Domain Admins and Enterprise Admins.
  67. Copy the files bellow from the subordinate CA server to a temporary folder on the domain controller:
    C:\Windows\System32\CertSrv\CertEnroll\*.crt
    Note: Copy the newest files
  68. Open Server Manager -> Tools -> Group Policy Management.
  69. From the left pane, expand the forest name -> expand Domains -> expand the relevant domain name -> right click on “Default domain policy” -> Edit.
  70. From the left pane, under “Computer Configuration” -> expand Policies -> expand “Windows Settings” -> expand “Security Settings” -> expand “Public Key Policies” -> right click on “Trusted Root Certification Authorities” -> Import -> click Next -> click Browse to locate the CRT file from the Root CA server -> click Open -> click Next twice -> click Finish -> click OK.
  71. From the left pane, under “Computer Configuration” -> expand Policies -> expand “Windows Settings” -> expand “Security Settings” -> expand “Public Key Policies” -> right click on “Intermediate Certification Authorities” -> Import -> click Next -> click Browse to locate the CRT file from the Subordinate CA server -> click Open -> click Next twice -> click Finish -> click OK.
  72. From the main pane, right click on the certificate name -> Properties -> OCSP tab -> inside the empty “Add URL” field, specify:
    http://www/ocsp
    Click on Add URL -> Click OK.
  73. From the left pane, under “Computer Configuration” -> expand Policies -> expand “Windows Settings” -> expand “Security Settings” -> click on “Public Key Policies” -> from the main pane, right click on “Certificate Services Client – Certificate Enrollment Policy” -> Properties -> change the “Configuration Model” to “Enabled” and click OK.
  74. From the left pane, under “Computer Configuration” -> expand Policies -> expand “Windows Settings” -> expand “Security Settings” -> click on “Public Key Policies” -> from the main pane, right click on “Certificate Services Client – Auto-Enrollment” -> Properties -> change the “Configuration Model” to “Enabled” -> select “Renew expired certificates, update pending certificates, and remove revoked certificates” and “Update certificates that use certificate templates” -> click OK.
  75. From the left pane, under “Computer Configuration” -> expand Policies -> expand “Administrative Templates” -> expand “Windows Components” -> expand “Internet Explorer” -> expand “Internet Control Panel” -> expand “Security Page” -> double click on “Site to zone assignment list” -> click on “Enabled” -> under Options, click on “Show” -> inside “Value name”, specify the Subordinate CA DNS name -> inside “Value”, specify 2 -> click OK twice.
  76. Close the “Group Policy Management”.
  77. Logoff the domain controller.
  78. Login to the Subordinate CA using administrative account.
  79. Open Server Manager -> Tools -> Internet Information Services (IIS) Manager.
  80. From the left pane, expand the server name -> expand Sites -> click on “Default Web Site” -> from the right pane, click on “Bindings” -> click on Add -> from the Type, select HTTPS -> under “SSL Certificate”, select the Subordinate CA certificate -> click OK -> click on Close.
  81. From the left pane, expand “Default Web Site” -> click on “CertSrv” -> from the main pane, double click on “Request Filtering” -> click Edit Feature Settings -> select “Allow Double Escaping” -> click OK
  82. From the main pane, double click on “SSL Settings” -> select “Require SSL” -> click on Apply.
  83. Close the Internet Information Services (IIS) Manager console.
  84. Run PKIVIEW.msc to make sure the entire PKI structure is fully functional.
  85. Logoff the Subordinate CA.

 

The original article can be found at:

http://security-24-7.com/windows-2012-r2-certification-authority-installation-guide/

Best Email Retention Policy Practices

Email retention policies are no longer just about conserving space on your Exchange server. Today you must take into account how your email retention controls increase or decrease risk to your company.

Pros and Cons of Short and Long Email Retention Policies

Generally speaking, longer email retention policies increase the risk that a security vulnerability or unauthorized user could expose your company’s secrets or embarrassing material. Long policies also increase your company’s exposure to legal examination that focuses on conversations and decisions captured in emails (this is also known as the “paper trail” in an “eDiscovery” process).

Shorter email retention policies help avoid these problems and are cheaper to implement, but they have their own significant disadvantages as well. First, short policies tend to annoy long-term employees and often executives, who rely on old email chains to recollect past decisions and the context in which they were made. Second, short policies may violate federal, state, local and/or industry regulations that require certain types of information to be retained for a minimum period of time – often years!

Best Practices to Develop Your Email Retention Policy

Obviously, you must balance these factors and others when you develop your own email retention policy, but there are a number of best practices that can help you draft and get support for a solid email retention policy. Today, I’ll be covering five practices often used by effective professionals and managers.

Email Retention Policy Best Practice #1: Start With Regulatory Minimums

Your email retention policy should begin by listing the various regulations your company is subject to and the relevant document retention requirements involved with each regulation.

Every industry is regulated differently, and businesses are often subject to different tax, liability and privacy regulations depending on the locations in which they do business. However, some common recommended retention periods include:

If a retention period is not known for a particular type of data, seven years (the minimum IRS recommendation) is often used as a safe common denominator.

Email Retention Policy Best Practice #2: Segment As Necessary To Avoid Keeping Everything For the Legal Maximum

As you can see from the list above, recommended retention periods vary widely even within highly regulated industries. With that in mind, it often pays to segment different types or uses of email into different retention periods to avoid subjecting your entire online email store to the maximum email retention period.

Segmentation by type of content looks something like this:

  • Invoices – 7 years
  • Sales Records – 5 years
  • Petty Cash Vouchers – 3 years

Segmentation by type of use looks something like this:

  • Administrative correspondence (e.g., human resources) – 5 years
  • Fiscal correspondence (e.g., revenue and expenses) – 4 years
  • General correspondence (e.g., customer interactions, internal threads) – 3 years
  • Ephemeral correspondence (e.g., everything else business-related) – 1 year
  • Spam – not retained

Mixed segmentation is also often common and looks something like this:

  • Human resources – 7 years
  • Transaction receipts – 3 years
  • Executive email – 2 years
  • Spam – not retained
  • Everything else (e.g., “default retention policy”) – 1 year

The rules and technologies you use to inspect, classify and segment can vary from simple sender- and subject-matching to sophisticated engines that intuit intent and history. (Unfortunately, space does not permit us to examine these technologies here, but trust me – they exist!)

Email Retention Policy Best Practice #3:

Draft a Real Policy…But Don’t Include What You Won’t Enforce

A written policy, approved by legal counsel and senior management, will give you the requirements and authority to implement all the IT, security and process controls you need. If you haven’t seen a full retention policy yet, please take the time to search the web for a few, such as this template from the University of Wisconsin(Go Badgers! Sorry…proud alum.)

Note that many “email retention policy” documents (including the UW template) cover much more than email! In general, this is OK because a “document policy” gives you what you need to implement an “email policy”, but you’ll want to make a point of talking the “document vs. email” terminology through with your legal team before you finalize your policy.

A good written policy (again, including the UW template) always contains these sections:

  • Purpose: why does this policy exist? If specific regulations informed the creation of this policy, they should all be listed here.
  • Retention time, by segment: how long various types of content or content used in a particular manner must be retained (the UW template segments by type of content). Durations are often listed in years, may include triggers (e.g., “after X”) and may even be “Permanent”.
  • Differences between “paper” and “electronic” documents: ideally, none.
  • What constitutes “destruction”: usually shredding and deleting, often “secure deletion” (e.g., with overwriting) and degaussing of media where applicable.
  • Pause destruction if legal action imminent: your legal department will normally add this for you, but you can show off your legal bona fides by including a clause instructing IT to pause automatic email deletion if the company becomes the subject of a claim or lawsuit (this is also called a “litigation hold”).
  • Who is responsible: typically everyone who touches the documents, often with special roles for certain titles (e.g., “Chief Archivist”) or groups (e.g., “legal counsel”).

Good written policies omit areas that you won’t or can’t support, especially types of segmentation you will not be able to determine or support. Good policies also refer to capabilities and requirements (e.g., offsite archival) rather than specific technologies and processes (e.g., DAT with daily courier shipments).

Email Retention Policy Best Practice #4: Price Preferred Solution and Alternatives By Duration and Segment

Let’s pretend that you have a policy like the following:

  • All email: retain on fast storage for 18 months
  • Purchase transaction emails : also archive to offline storage until 5 years have passed
  • Legal emails: also archive to offline storage until 7 years have passed
  • “Fast storage” = accessible through end user’s email clients through “folders”; normally only individual users can access, but administrators and archival specialists (e.g., the legal team) can access too
  • “Offline storage” = accessible through internal utility and search; only administrators and archival specialists (e.g., the legal team) can access

To price an appropriate solution, you would restate your requirements based on number of users, expected volume of email and expected rate of growth. For example, in a 500-person company where each user averaged 1MB and 100 messages of email a day, there were 5000 additional transaction emails (total 50MB) a day and 100 additional legal emails (total 20MB) a day, and volumes were expected to increase 10% per year, here’s how we might estimate minimum requirements for the next seven years:

  • All email: 18 months x 1MB/day-person x 30 days/month x 500 people = 270GB x 1.8 (about 10% increase in 6 years) = 486GB email server storage
  • Purchase transaction emails: 5 years x 12 months/year x 30 days/month x 50MB/day = 90GB x 1.8 = 162GB email archive storage
  • Legal emails: 7 years x 12 months/year x 30 days/month x 20MB/day = 50GB x 1.8 = 91GB email archive storage
  • TOTAL: 486GB server + 253GB archive

However, after you’ve priced out your preferred solution, you still need to be prepared to handle alternatives that may result from discussions with legal or your executive team. For example, if the executive team pushes your 18 month blanket retention to 3 years and the legal team “requires” that its emails are always in near-term email storage, how would that change your requirements and pricing?

  • All email: 36 months x 1MB/day-person x 30 days/month x 500 people = 540GB x 1.8 (about 10% increase in 6 years) = 972GB email server storage
  • Purchase transaction emails: 5 years x 12 months/year x 30 days/month x 50MB/day = 90GB x 1.8 = 162GB email archive storage
  • Legal emails: 7 years x 12 months/year x 30 days/month x 20MB/day = 50GB x 1.8 = 91GB email server storage
  • TOTAL: 1063GB server + 192GB archive (e.g., DOUBLE your realtime storage!)

Long story short, if you can figure out your own rule-of-thumb per-GB price for the various types of storage necessary to support your archiving scheme (as well as licensing considerations, including any per-message or per-type-of-message rules) you’ll be better prepared for “horse trading” later in the approval process.

Email Retention Policy Best Practice #5: Once You Draft Your Policy, Include Legal Before the Executives

If you’re still reading this, chances are good that you (like me) are a senior IT or security professional, or are perhaps even a manager. If you’ve drafted other IT policies, such as an “acceptable use” policy, your first instinct might be to keep your legal team out of the process until your new policy has snowballed down from your IT-based executive sponsor. This is almost always a mistake.

The main reason legal should be included as soon as you have a draft is that two of the best practices listed above (regulatory minimums and viability of segmentation) are really legal’s call – not yours! You will have saved legal a lot of legwork by researching the main drivers of email retention policy and the technical controls you can use to enforce the policy, but at the end of the day legal will be called upon to defend the company’s decision to keep or toss critical information, so legal will need to assign the final values to your policy limits.

A second reason to include legal before your executives is that you want to present a unified front (as IT and legal) on your maximum retention limits. Once you get into negotiations with your executive team, legal will likely be pushing for even shorter limits (because it limits the threat of hostile eDiscovery) and the executives will be pushing for even longer limits (because email is their old document storage). This puts you (as IT) in the rational middle and gives your policy a good chance of making it through the negotiations relatively unscathed.

The final reason you want to include legal early is that their calls may force you to reprice the options you laid out before you talked to them, and may cause you to take some options off the table. If you reversed the process and got executives to sign off on a solution that got vetoed by legal and sent back to the executive team for a second round of “ask,” I think you know that no one would be happy.

Conclusion: Your Email Retention Policy Will Be Your Own

Given all the different constraints your organization faces and all the different ways your interactions with your legal and executive team could go, it would be impossible for me to predict what any company’s email retention policy would be. However, if you follow these five best practices when you develop your own, you stand a better-than-average chance of drafting an email retention policy that’s sensible, enforceable, and loved by legal and top management alike.