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/

Share

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.

Share

AV is dead … again …

Antivirus software only catches 45% of malware attacks and is “dead”, according to a senior manager at Symantec.”

85.4% of statistic can be interpreted in the opposite way, and AV has been declared dead regularly since 1987.

Symantec “invented commercial antivirus software in the 1980s”?  That must come as news to the many companies, like Sophos, that I was reviewing long before Symantec bought out their first AV company.

“Dye told the Wall Street Journal that hackers increasingly use novel methods and bugs in the software of computers to perform attacks.”

There were “novel attacks” in 1986, and they got caught.  There have been novel attacks every year or so since, and they’ve been caught.  At the same time, lots of people get attacked and fail to detect it.  There’s never a horse that couldn’t be rode, and there’s never a rider that couldn’t be throwed.

“Malware has become increasingly complex in a post-Stuxnet world.”

So have computers.  Even before Stuxnet.  I think it was Grace Hopper who said that the reason it is difficult to secure complex systems is because they are complex systems.  (And she died a while back.)

Share

Settle for nothing now … Settle for nothing later!

We settle for this. We, the consumers, are the problem! I don’t have much more to say…a picture is worth a thousand words.

bug bonanza

Share

Big Government vs Big Corp – which is worse?

A programmer has been banned from Google for life.

This appears to be kind of like those Kafka-esque errors that big government sometimes make [1] (and which reinforce the arguments against the “if you’re not doing anything wrong you don’t need privacy” position), with the added factor that there is absolutely nothing that can be done about it.

I suppose an individual programmer could bring civil suit against Google (and its undoubtedly huge population of lawyers) citing material damages for being forbidden from participating in the Google/Play/app store, but I wouldn’t be too sanguine about his chances of succeeding …

 

[1] – since the foreign workers program seems to be being used primarily to bring in workers for the oil and gas sector right now, do you think it would help if she offered to mount a production of “Grease”?

Share

Disasters in BC

The auditor general has weighed in, and, surprise, surprise, we are not ready for an earthquake.

On the one hand, I’m not entirely sure that the auditor general completely understands disaster planning, and she hasn’t read Kenneth Myers and so doesn’t know that it can be counter-productive to produce plans for every single possibility.

On the other hand, I’m definitely with Vaugh Palmer in that we definitely need more public education.  We are seeing money diverted from disaster planning to other areas, regardless of a supposed five-fold increase in emergency budget.  In the past five years, the professional association has been defunded, training is very limited in local municipalities, and even recruitment and “thank you” events for volunteers have almost disappeared.  Emergency planning funds shouldn’t be used to pay for capital projects.

(And the province should have been prepared for an audit in this area, since they got a warning shot last year.)

So, once again, and even more importantly, I’d recommend you all get emergency training.  I’ve said it beforeI keep saying itI will keep on saying it.

(Stephen Hume agrees with me, although he doesn’t know the half of it. )

Share

New computers – Windows 8 Phone

I was given a Win8Phone recently.  I suppose it may seem like looking a gift horse in the mouth to review it, but:

I must say, first off, that the Nokia Lumia has a lot of power compared to my other phone (and Android tablets), so I like the responsiveness using Twitter.  The antenna is decent, so I can connect to hotspots, even at a bit of a distance.  Also, this camera is a lot better than those on the three Android machines.

I’m finding the lack of functionality annoying.  There isn’t any file access on the phone itself, although the ability to access it via Windows Explorer (when you plug the USB cable into a Windows 7 or 8 computer) is handy.

I find the huge buttons annoying, and the interface for most apps takes up a lot of space.  This doesn’t seem to be adjustable: I can change the size of the font, but only for the content of an app, not for the frame or surround.

http://www.windowsphone.com/en-us/how-to/wp8 is useful: that’s how I found out how to switch between apps (hold down the back key and it gives you a set of
icons of running/active apps).

The range of apps is pathetic.  Security aside (yes, I know a closed system is supposed to be more secure), you are stuck with a) Microsoft, or b) completely unknown software shops.  You are stuck with Bing for search and maps: no Google, no Gmail.  You are stuck with IE: no Firefox, Chrome, or Safari.  Oh, sorry, yes you *can* get Firefox, Chrome, and Safari, but not from Mozilla, Google, or Apple: from developers you’ve never heard of.  (Progpack, maker(s) of the Windows Phone store version of Safari, admits it is not the real Safari, it just “looks like it.”)  You can’t get YouTube at all.  No Pinterest, although there is a LinkedIn app from LinkedIn, and a Facebook app–from Microsoft.

It’s a bit hard to compare the interface.  I’m comparing a Nokia Lumia 920 which has lots of power against a) the cheapest Android cell phone Bell had when I had to upgrade my account (ver 2.2), b) an Android 4.3 tablet which is really good but not quite “jacket” portable, and c) a Digital2 Android 4.1 mini-tablet which is probably meant for children and is *seriously* underpowered.

Don’t know whether this is the fault of Windows or the Nokia, but the battery indicators/indications are a major shortcoming.  I have yet to see any indication that the phone has been fully charged.  To get any accurate reading you have to go to the battery page under settings, and even that doesn’t tell you a heck of a lot.  (Last night when I turned it off it said the battery was at 46% which should be good for 18 hours.  After using it four times this morning for a total of about an hour screen time and two hours standby it is at 29%.)

(When I installed the Windows Phone app on my desktop, and did some file transfers while charging the phone through USB I found that the app has a battery level indicator on most pages, so that’s helpful.)

Share

Enhanced Nigerian scam – linkedin style

Linkedin is a much better platform for Nigerian scammers: They now have my first and last name, information about me, etc. So they can craft the following letter (sent by this guy):

Hello Aviram Jenik,

I am Dr Sherif Akande, a citizen of Ghana, i work with Barclay’s Bank Ltd, Ghana. I have in my bank Existence of the Amount of money valued at $8.400,000.00, the big hurt Belongs to the customer, Peter B.Jenik, who Happen To Have The Same name as yours. The fund is now without any Claim Because, Peter B.Jenik, in a deadly earthquake in China in 2008. I want your cooperation so that bank will send you the fund as the beneficiary and located next of kin to the fund.

This transaction will be of a great mutual assistance to us. Send me your reply of interest so that i will give you the details. Strictly send it to my private email account {sherifakande48@gmail.com} or send me your email address to send you details of this transaction.

At the receipt of your reply, I will give you details of the transaction.I look forward to hear from you. I will send you a scan copy of the deposit certificate.

Send me an email to my private email account {sherifakande48@gmail.com}for more details of the transaction.

Sincerely,
Best Regard’s
Dr Sherif Akande.
Here is my number +233548598269

Share

Card fraud and other details

A family member recently encountered credit card fraud.  That isn’t unusual, but there were some features of the whole experience that seemed odd.

First off, the person involved is certain that the fraud relates to the use of the card at a tap/RFID/proximity reader.  The card has been in use for some time, but the day before the fraudulent charges the card was used, for the first time, at a gas pump with a “tap” reader.

(I suspect this is wrong.  The card owner feels that gas pumps, left unattended all night, would be a prime target for reader tampering.  I can’t fault that logic, but the fact that an address was later associated with use of the card makes me wonder.)

At any rate, the day after the gas was purchased, two charges were made with the credit card.  One was for about $600.00, and was with startech.com, a supplier of computer parts, particularly cables, based in Ontario.  The other charge was for almost $4000.00, and was with megabigpower.com, which specializes in hardware devices for Bitcoin mining, and operates out of Washington state.  (Given the price list, this seems consistent with about 8 Bitcoin mining cards, or about 20 USB mining devices.)  The credit card company was notified, and the card voided and re-issued.

A few days after that, two boxes arrived–at the address of the cardholder.  One came from startech.com via UPS and was addressed to John Purcer, the other was from megabigpower.com via Fedex and was addressed to Tom Smyth.  Both were left at the door, refused and returned to the delivery companies.  (At last report, the cardholder was trying to get delivery tracking numbers to ensure that the packages were returned to the companies.)

As noted previously, this is where I sat up.  Presumably a simple theft of the card data at a reader could not provide the cardholder’s address data.  An attempt might be made to ensure that the “ship to” address is the same as the “bill to” address (one of the companies says as much on its billing page), but I further assume that a call to the credit card company with a “hey, I forgot my address” query wouldn’t fly, and I doubt the credit card company would even give that info to the vendor company.

One further note: I mentioned to the cardholder that it was fortunate that the shipment via UPS was from the Canadian company, since UPS is quite unreasonable with charges (to the deliveree) involving taking anything across a border.  (When I was doing a lot more book reviews in the old days, I had to add a standard prohibition against using UPS to all my correspondence with companies outside Canada.)  When UPS was contacted about this delivery, the agent reported that the package was shown as delivered, with a note of “saw boy,” presumably since the cardholder’s son was home, or in the vicinity of the house, at the time of delivery.  The cardholder was understandably upset and asked to have that note taken off the record, and was then told a) the record could not be changed, and b) that was a standard code, presumably built-in to the tracking devices the drivers carry.

Just a note to those of you who care anything about privacy …

Share

REVIEW: “Rainbows End”, Vernor Vinge

BKRNBSND.RVW   20130525

“Rainbows End”, Vernor Vinge, 2006, 0-312-85684-9, U$25.95/C$34.95
%A   Vernor Vinge
%C   175 Fifth Avenue, New York, NY  10010
%D   2006
%G   0-312-85684-9
%I   Tor Books/Tom Doherty Assoc.
%O   U$25.95/C$34.95 pnh@tor.com www.tor.com
%O  http://www.amazon.com/exec/obidos/ASIN/0312856849/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0312856849/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0312856849/robsladesin03-20
%O   Audience i+ Tech 2 Writing 3 (see revfaq.htm for explanation)
%P   364 p.
%T   “Rainbows End”

It is always a pleasure to read something from Vinge.  His characters are interesting, his plots sufficiently convoluted, and his writing clear and flowing.  In addition, for the geek, his understanding of the technology is realistic and fundamental, which makes a change from so many who merely parrot jargon they do not comprehend.

Of course, this is future technology we are talking about, so none of it is (currently) real.  But it could be, without the wild flights of illogic that so abound in fiction.

In this book, we have a future with interconnectedness around the globe.  Of course, this means that there are dangers, in regard to identity and authentication.  The new technology protects against these dangers with a Secure Hardware Environment.  (Or SHE, and, since the DHS mandates that everyone must use it, does that make it SHE-who-must-be-obeyed?)

Encryption is, of course, vital to the operations, and so is used a lot, often in multiple layers.  It is probably a measure of the enjoyability of Vinge’s work that I really didn’t take note of the fact that two of the characters were named Alice and Bob.  Not, that is, until late in the volume, when the author also briefly introduces a character named Eve Mallory.

copyright, Robert M. Slade   2013   BKRNBSND.RVW   20130525

Share

Best CTF in the history of CTFs ;)

This is a ton of fun, and a great tool for learning. Enjoy!

http://www.matasano.com/matasano-square-microcontroller-ctf/

Share

CyberSec Tips – “Computer Maintenance Department”

I got a call today from “James,” of the “computer maintenance department.”

I suppose this may work better against those who actually have a computer maintenance department.  Since I’m self-employed, it’s pretty obvious that this is phony.  Sometimes, though, “James” or his friends call from Microsoft or other such possibilities.

Just in case anyone doesn’t know, these are false, attempts to get you to damage your own computer, or install something nasty.  They can then charge you for spurious repairs, add you to a botnet, or mine your computer for account information.

Oh, and also, as chance would have it, today I got my first completely automated spam/fraud/telemarketing call: a computer generated voice and voice response system, asking how I was, and then, when I didn’t respond, was I there.  Probably would have been fun to try and push the limits of it’s capability, but I didn’t have time …

Share

Cyberbullying, anonymity, and censorship

Michael Den Tandt’s recent column in the Vancouver Sun is rather a melange, and deserves to have a number of points addressed separately.

First, it is true that the behaviours the “cyberbullying” bill address, those of spreading malicious and false information widely, generally using anonymous or misleading identities, do sound suspiciously close to those behaviours in which politicians engage themselves.  It might be ironic if the politicians got charged under the act.

Secondly, whether bill C-13 is just a thinly veiled re-introduction of the reviled C-30 is an open question.  (As one who works with forensic linguistics, I’d tend to side with those who say that the changes in the bill are primarily cosmetic: minimal changes intended to address the most vociferous objections, without seriously modifying the underlying intent.)

However, Den Tandt closes with an insistence that we need to address the issue of online anonymity.  Removing anonymity from the net has both good points and bad, and it may be that the evil consequences would outweigh the benefits.  (I would have thought that a journalist would have been aware of the importance of anonymous sources of reporting.)

More importantly, this appeal for the banning of anonymity betrays an ignorance of the inherent nature of networked communitcation.  The Internet, and related technologies, have so great an influence on our lives that it is important to know what can, and can’t, be done with it.

The Internet is not a telephone company, where the central office installs all the wires and knows at least where (and therefore likely who) a call came from.  The net is based on technology whish is designed, from the ground up, in such a way that anyone, with any device, can connect to the nearest available source, and have the network, automatically, pass information to or from the relevant person or site.

The fundamental technology that connects the Internet, the Web, social media, and pretty much everything else that is seen as “digital” these days, is not a simple lookup table at a central office.  It is a complex interrelationship of prototcols, servers, and programs that are built to allow anyone to communicate with anyone, without needing to prove your identity or authorization.  Therefore, nobody has the ability to prevent any communication.

There are, currently, a number of proposals to “require” all communications to be identified, or all users to have an identity, or prevent anyone without an authenticated identity from using the Internet.  Any such proposals will ultimately fail, since they ignore the inherent foundational nature of the net.  People can voluntarily participate in such programs–but those people probably wouldn’t have engaged in cyberbullying in any case.

John Gilmore, one of the people who built the basics of the Internet, famously stated that “the Internet interprets censorship as damage and routes around it.”  This fact allows those under oppressive regimes to communicate with the rest of the world–but it also means that pornography and hate speech can’t be prevented.  The price of reasonable commuincations is constant vigilance and taking the time to build awareness.  A wish for a technical or legal shortcut that will be a magic pill and “fix” everything is doomed to fail.

Share

BananaGlee

BananaGlee. I just love saying that word ;)

So, was reading up on the NSA backdoors for Cisco and other OSes, http://cryptome.org/2014/01/nsa-codenames.htm, and got to thinking about how the NSA might exfiltrate their data or run updates…It’s gotta be pretty stealthy, and I’m sure they have means of reflecting data to/from their Remote Operations Center (ROC) in such a way that you can’t merely look at odd destination IPs from your network.

This got me thinking about how I would find such data on a network. First off, obviously, I’d have to tap the firewall between firewall and edge router. I’d also want to tap the firewall for all internal connections. Each of these taps would be duplicated to a separate network card on a passive device.

1) eliminate all traffic that originated from one interface and went out another interface. This has to be an exact match. I would think any changes outside of TTL would be something that would have to be looked at.

2) what is left after (1) would have to be traffic originating from the firewall (although not necessarily using the firewalls IP or MAC). That’s gotta be a much smaller set of data.

3) With the data set from (2), you’ve gotta just start tracing through each one.

This would, no doubt, be tons of fun. I don’t know how often the device phones home to the ROC, what protocol they might use , etc…

If anyone has any ideas, I’d love to hear them. I find this extremely fascinating.

dmitry.chan@gmail.com

Share

Hardening guide for NGINX 1.5.8 on RedHat 6.4 (64bit edition)

This document explains the process of installation, configuration and hardening of NGINX server from source files, based on CentOS 6.4 default installation (IPTables and SELinux enabled by default), including support for TLS v1.2 and protection from BEAST attack and CRIME attack
 
Some of the features explained in this document are supported by only some of the Internet browsers:

  • X-Frame-Options – Minimum browser support: IE 8.0, Firefox 3.6.9, Chrome 4.1.249, Opera 10.50, Safari 4.0
  • TLS 1.2 – Minimum browser support: IE 8.0 on Windows 7/8 (Need to be enabled by default), Firefox 24.0 (Need to be enabled by default), Chrome 30, Opera 17, Safari 5.0
    1. Installation Phase

    2. Login to the server using Root account
    3. Install pre-requirement packages:
      yum install policycoreutils-python-* -y
      yum install setools-libs-* -y
      yum install libcgroup-* -y
      yum install audit-libs-python-* -y
      yum install libsemanage-python-* -y
      yum install setools-libs-python-* -y
      yum install gcc* -y
    4. Create a new account:
      groupadd nginx

      useradd -g nginx -d /dev/null -s /sbin/nologin nginx

    5. Upgrade the Openssl build:
      rpm -ivh --nosignature http://rpm.axivo.com/redhat/axivo-release-6-1.noarch.rpm

      yum --enablerepo=axivo update openssl -y

    6. Download Openssl source files:
      cd /opt

      wget http://www.openssl.org/source/openssl-1.0.1e.tar.gz

    7. Extract Openssl source files:
      tar zxvf /opt/openssl-1.0.1e.tar.gz -C /opt
    8. Remove Openssl source file:
      rm -rf /opt/openssl-1.0.1e.tar.gz
    9. Download PCRE source file into /tmp, from:
      http://sourceforge.net/projects/pcre/files/pcre/
    10. Compile PCRE from source file:
      tar zxvf /tmp/pcre-8.34.tar.gz -C /tmp

      mv /tmp/pcre-8.34 /usr/local/pcre

      cd /usr/local/pcre

      ./configure --prefix=/usr/local/pcre

      make

      make install

    11. Remove PCRE package:
      rm -rf /tmp/pcre-8.34.tar.gz
    12. Download Nginx 1.5.8:
      cd /tmp

      wget http://nginx.org/download/nginx-1.5.8.tar.gz

    13. Extract the nginx-1.5.8.tar.gz file:
      tar -zxvf /tmp/nginx-1.5.8.tar.gz -C /tmp
    14. Move to the Nginx source folder:
      cd /tmp/nginx-1.5.8
    15. Edit using VI, the file
      /tmp/nginx-1.5.8/src/http/ngx_http_header_filter_module.c and replace the following section, from:
      static char ngx_http_server_string[] = "Server: nginx" CRLF;

      static char ngx_http_server_full_string[] = "Server: " NGINX_VER CRLF;
      To:
      static char ngx_http_server_string[] = "Server: Secure Web Server" CRLF;
      static char ngx_http_server_full_string[] = "Server: Secure Web Server" NGINX_VER CRLF;

    16. Run the commands bellow to compile the Nginx environment:
      ./configure --with-openssl=/opt/openssl-1.0.1e --with-http_ssl_module --without-http_autoindex_module --without-http_ssi_module --with-pcre=/usr/local/pcre
      Note: The command above should be written as one line.
      make

      make install

    17. Remove the Nginx source files:
      cd /

      rm -rf /tmp/nginx-1.5.8

      rm -f /tmp/nginx-1.5.8.tar.gz

    18. Remove Default Content
      rm -rf /usr/local/nginx/html
    19. Updating Ownership and Permissions on Nginx folders:
      chown -R root:root /usr/local/nginx

      chmod 750 /usr/local/nginx/sbin/nginx

      chmod -R 640 /usr/local/nginx/conf

      chmod -R 770 /usr/local/nginx/logs

    20. Create folder for the web content:
      mkdir -p /www
    21. Updating Ownership and Permissions on the web content folder:
      chown -R root /www

      chmod -R 775 /www

    22. Edit using VI the file /usr/local/nginx/conf/nginx.conf and change the following settings:
      From:
      #user nobody;
      To:
      user nginx nginx;

      From:
      #error_log logs/error.log notice;
      To:
      error_log logs/error.log notice;

      From:
      server_name localhost;
      To:
      server_name Server_FQDN;
      Note: Replace Server_FQDN with the actual server DNS name.

      From:
      root html;
      To:
      root /www;

    23. Add the following sections to the end of the /usr/local/nginx/conf/nginx.conf file (before the last “}” character):
      ## turn off nginx version number ##
      server_tokens off;
      ## Size Limits & Buffer Overflows ##
      client_body_buffer_size 1K;
      client_header_buffer_size 1k;
      client_max_body_size 1k;
      large_client_header_buffers 2 2k;
      ## Timeouts ##
      client_body_timeout 10;
      client_header_timeout 10;
      send_timeout 10;
    24. Create using VI, the file /etc/init.d/nginx with the following content:
      #!/bin/sh
      #
      # nginx - this script starts and stops the nginx daemon
      #
      # chkconfig: - 85 15
      # description: Nginx is an HTTP(S) server, HTTP(S) reverse \
      # proxy and IMAP/POP3 proxy server
      # processname: nginx
      # config: /usr/local/nginx/conf/nginx.conf
      # config: /etc/sysconfig/nginx
      # pidfile: /var/run/nginx.pid

      # Source function library.
      . /etc/rc.d/init.d/functions

      # Source networking configuration.
      . /etc/sysconfig/network

      # Check that networking is up.
      [ "$NETWORKING" = "no" ] && exit 0

      nginx="/usr/local/nginx/sbin/nginx"
      prog=$(basename $nginx)

      NGINX_CONF_FILE="/usr/local/nginx/conf/nginx.conf"

      [ -f /etc/sysconfig/nginx ] && . /etc/sysconfig/nginx

      lockfile=/var/lock/subsys/nginx

      start() {
      [ -x $nginx ] || exit 5
      [ -f $NGINX_CONF_FILE ] || exit 6
      echo -n $"Starting $prog: "
      daemon $nginx -c $NGINX_CONF_FILE
      retval=$?
      echo
      [ $retval -eq 0 ] && touch $lockfile
      return $retval
      }

      stop() {
      echo -n $"Stopping $prog: "
      killproc $prog -QUIT
      retval=$?
      echo
      [ $retval -eq 0 ] && rm -f $lockfile
      return $retval
      }

      restart() {
      configtest || return $?
      stop
      sleep 1
      start
      }

      reload() {
      configtest || return $?
      echo -n $"Reloading $prog: "
      killproc $nginx -HUP
      RETVAL=$?
      echo
      }

      force_reload() {
      restart
      }

      configtest() {
      $nginx -t -c $NGINX_CONF_FILE
      }

      rh_status() {
      status $prog
      }

      rh_status_q() {
      rh_status >/dev/null 2>&1
      }

      case "$1" in
      start)
      rh_status_q && exit 0
      $1
      ;;
      stop)
      rh_status_q || exit 0
      $1
      ;;
      restart|configtest)
      $1
      ;;
      reload)
      rh_status_q || exit 7
      $1
      ;;
      force-reload)
      force_reload
      ;;
      status)
      rh_status
      ;;
      condrestart|try-restart)
      rh_status_q || exit 0
      ;;
      *)
      echo $"Usage: $0 {start|stop|status|restart|condrestart|try-restart|reload|force-reload|configtest}"
      exit 2
      esac

    25. Change the permissions of the file /etc/init.d/nginx
      chmod +x /etc/init.d/nginx
    26. To start Nginx service at server start-up, run the command:
      chkconfig nginx on
    27. To manually start the Nginx service, use the command:
      /etc/init.d/nginx start
    28. Configure IPTables:
      service iptables stop

      iptables -P INPUT DROP

      iptables -A INPUT -i lo -j ACCEPT

      iptables -A OUTPUT -o lo -j ACCEPT

      iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

    29. Allow SSH access from Internal segment (i.e. 10.0.0.0/8)
      iptables -A INPUT -m state --state NEW -p tcp --dport 22 -s 10.0.0.0/8 -j ACCEPT
      Note: Replace 10.0.0.0/8 with the internal segment and subnet mask.
    30. Allow HTTP access from the Internet on the public interface (i.e. eth0)
      iptables -A INPUT -m state --state NEW -p tcp --dport 80 -i eth0 -j ACCEPT
      Note: Replace eth0 with the public interface name.
    31. Save the IPTables settings:
      service iptables save
      SSL Configuration Phase

    1. Login to the server using Root account.
    2. Create folder for the SSL certificate files:
      mkdir -p /usr/local/nginx/ssl

      chmod 600 /usr/local/nginx/ssl

    3. Run the command bellow to generate a key pair:
      /usr/bin/openssl genrsa -aes256 -out /usr/local/nginx/ssl/server-sec.key 2048
      Note: Specify a complex pass phrase for the private key (and document it)
    4. Run the command bellow to generate the CSR:
      /usr/bin/openssl req -new -newkey rsa:2048 -nodes -sha256 -days 1095 -key /usr/local/nginx/ssl/server-sec.key -out /tmp/server.csr
      Note: The command above should be written as one line.
    5. Send the file /tmp/server.csr to a Certificate Authority server.
    6. As soon as you receive the signed public key from the CA server via email, copy all lines starting with “Begin” and ending with “End” (include those two lines), into notepad, and save the file as “server.crt”
    7. Copy the file “server.crt” using SCP into /usr/local/nginx/ssl
    8. Follow the link on the email from the CA server, to create the Root CA chain, and save it as “ca-bundle.crt” (Note: The file must be PEM (base64) encoded).
    9. Copy the file “ca-bundle.crt” using SCP into /usr/local/nginx/ssl
    10. Combine the content of both the public key (server.crt) and the Root CA chain (ca-bundle.crt) into one file:
      cat /usr/local/nginx/ssl/ca-bundle.crt /usr/local/nginx/ssl/server.crt > /usr/local/nginx/ssl/server.pem
      Note: The command above should be written as one line.
    11. Remove the key store passphrase:
      /usr/bin/openssl rsa -in /usr/local/nginx/ssl/server-sec.key -out /usr/local/nginx/ssl/server.key
      Note: The command above should be written as one line.
    12. Remove the original “server.crt”, “server.csr” and “ca-bundle.crt” files:
      rm -f /tmp/server.csr

      rm -f /usr/local/nginx/ssl/server.crt

      rm -f /usr/local/nginx/ssl/ca-bundle.crt

    13. Edit using VI the file /usr/local/nginx/conf/nginx.conf and replace the section bellow from:
      # HTTPS server
      #
      #server {
      # listen 443 ssl;
      # server_name localhost;
      # ssl_certificate cert.pem;
      # ssl_certificate_key cert.key;
      # ssl_session_cache shared:SSL:1m;
      # ssl_session_timeout 5m;
      # ssl_ciphers HIGH:!aNULL:!MD5;
      # ssl_prefer_server_ciphers on;
      # location / {
      # root html;
      # index index.html index.htm;
      # }
      #}

      To:
      # HTTPS server
      #
      server {
      listen 443;
      server_name Server_FQDN;
      ssl on;
      ssl_certificate /usr/local/nginx/ssl/server.pem;
      ssl_certificate_key /usr/local/nginx/ssl/server.key;
      ssl_session_timeout 5m;
      ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
      ssl_ciphers EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS:!aNULL:!EDH:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS;
      ssl_prefer_server_ciphers on;
      # HTTP Strict Transport Security #
      add_header Strict-Transport-Security max-age=63072000;
      # X-Frame-Options header #
      add_header X-Frame-Options SAMEORIGIN;
      location / {
      root /www;
      index index.html index.htm;
      }
      }

      Note: Replace Server_FQDN with the actual server DNS name.
    14. Configure IPTables – Allow HTTPS access from the Internet on the public interface (i.e. eth0)
      iptables -A INPUT -m state --state NEW -p tcp --dport 443 -i eth0 -j ACCEPT
      Note: Replace eth0 with the public interface name
    15. Remove HTTP access from the Internet on the public interface (i.e. eth0)
      iptables -D INPUT -m state --state NEW -p tcp --dport 80 -i eth0 -j ACCEPT
      Note: Replace eth0 with the public interface name
    16. Save the IPTables settings:
      service iptables save
    17. Restart the nginx:
      service nginx restart

    The original article can be found on:
    http://security-24-7.com/hardening-guide-for-nginx-1-5-8-on-redhat-6-4-64bit-edition/

    Share

    Crafting a Pen Testing Report

    You close the lid of your laptop; it’s been a productive couple of days. There are a few things that could be tightened up, but overall the place isn’t doing a bad job. Exchange pleasantries with the people who have begrudgingly given up time to escort you, hand in your visitors badge and head for the door. Just as you feel the chill of outside against your skin, you hear a muffed voice in the background.

    “Hey, sorry, I forgot to ask, when can we expect the report?”

    Sound familiar?

    Ugh, the report. Penetration testing’s least favorite cousin, but ultimately, one of the most important.

    There are thousands of books written about information security and pen testing. There are hundreds of hours of training courses that cover the penetration testing process. However, I would happily wager that less than ten percent of all the material out there is dedicated to reporting. This, when you consider that you probably spend 40-50% of the total duration of a pen test engagement actually writing the report, is quite alarming.

    It’s not surprising though, teaching someone how to write a report just isn’t as sexy as describing how to craft the perfect buffer overflow, or pivot round a network using Metasploit. I totally get that, even learning how the TCP packet structure works for the nineteenth time sounds like a more interesting topic.

    A common occurrence amongst many pen testers. Not allowing enough time to produce a decent report.

    No matter how technically able we are as security testers, it is often a challenge to explain a deeply technical issue to someone who may not have the same level of technical skill. We are often guilty of making assumptions that everyone who works in IT has read the same books, or has the same interests as us. Learning to explain pen test findings in a clear and concise way is an art form, and one that every security professional should take the time to master. The benefits of doing so are great. You’ll develop a better relationship with your clients, who will want to make use of your services over and over again. You’ll also save time and money, trust me. I once drove a 350 mile round trip to go and explain the contents of a penetration test report to a client. I turned up, read some pages of the report aloud with added explanations and then left fifteen minutes later. Had I taken a tiny bit more time clarifying certain issues in my report, I would have saved an entire day of my time and a whole tank of gas.

    Diluted: “SSH version one should be disabled as it contains high severity vulnerabilities that may allow an attacker already on the network to intercept and decrypt communications, although the risk of an attacker gaining access to the network is very low, so this reduces the severity.”

    Clarified: “It is advisable to disable SSH version one on these devices, failure to do so could allow an attacker with local network access to decrypt and intercept communications.”

    Why is a penetration test report so important?

    Never forget, penetration testing is a scientific process, and like all scientific processes it should be repeatable by an independent party. If a client disagrees with the findings of a test, they have every right to ask for a second opinion from another tester. If your report doesn’t detail how you arrived at a conclusion, the second tester will have no idea how to repeat the steps you took to get there. This could lead to them offering a different conclusion, making you look a bit silly and worse still, leaving a potential vulnerability exposed to the world.

    Bad: “Using a port scanner I detected an open TCP port”.

        Better: “Using Nmap 5.50, a port scanner, I detected an open TCP port using the SYN scanning technique on a selected range of ports. The command line was: nmap –sS –p 7000-8000.”

    The report is the tangible output of the testing process, and the only real evidence that a test actually took place. Chances are, senior management (who likely approved funding for the test) weren’t around when the testers came into the office, and even if they were, they probably didn’t pay a great deal of attention. So to them, the report is the only thing they have to go on when justifying the expense of the test. Having a penetration test performed isn’t like any other type of contract work. Once the contract is done there is no new system implemented, or no new pieces of code added to an application. Without the report, it’s very hard to explain to someone what exactly they’ve just paid for.

    Who is the report for?

    While the exact audience of the report will vary depending on the organization, it’s safe to assume that it will be viewed by at least three types of people.

    Senior management, IT management and IT technical staff will all likely see the report, or at least part of it. All of these groups will want to get different snippets of information. Senior management simply doesn’t care, or doesn’t understand what it means if a payment server encrypts connections using SSL version two. All they want to know is the answer to one simple question “are we secure – yay or nay?”

    IT management will be interested in the overall security of the organization, but will also want to make sure that their particular departments are not the cause of any major issues discovered during testing. I recall giving one particularly damming report to three IT managers. Upon reading it two of them turned very pale, while the third smiled and said “great, no database security issues then”.

    IT staff will be the people responsible for fixing any issues found during testing. They will want to know three things. The name of the system affected, how serious the vulnerability is and how to fix it. They will also want this information presented to them in a way that is clear and organized. I find the best way is to group this information by asset and severity. So for example, “Server A” is vulnerable to “Vulnerability X, Y and Z. Vulnerability Y is the most critical”. This gives IT staff half a chance of working through the list of issues in a reasonable timeframe. There is nothing worse than having to work your way backwards and forwards through pages of report output to try and keep track of vulnerabilities and whether or not they’ve been looked at.

    Of course, you could always ask your client how they would like vulnerabilities grouped. After all, the test is really for their benefit and they are the people paying! Some clients prefer to have a page detailing each vulnerability, with affected assets listed under the vulnerability title. This is useful in situations where separate teams may all have responsibilities for different areas of a single asset. For example, the systems team runs the webserver, but the development team writes the code for the application hosted on it.

    Although I’ve mentioned the three most common audiences for pen test reports, this isn’t an exhaustive list. Once the report is handed over to the client, it’s up to them what they do with it. It may end up being presented to auditors, as evidence that certain controls are working. It could be presented to potential customers by the sales team. “Anyone can say their product is secure, but can they prove it? We can, look here is a pen test report”.

    Reports might even end up getting shared with the whole organization. It sounds crazy, but it happens. I once performed a social engineering test, the results of which were less than ideal for the client. The enraged CEO shared the report with the whole organization, as a way of raising awareness of social engineering attacks. This was made more interesting, when I visited that same company a few weeks later to deliver some security awareness training. During my introduction, I explained that my company did security testing and was responsible for the social engineering test a few weeks back. This was greeted with angry stares and snide comments about how I’d gotten them all into trouble. My response was, as always, “better to give me your passwords than a genuine bad guy”.

    What should the report contain?

    Sometimes you’ll get lucky and the client will spell out exactly what they want to see in the report during the initial planning phase. This includes both content and layout. I’ve seen this happen to extreme levels of detail, such as what font size and line spacing settings should be used. However, more often than not, the client won’t know what they want and it’ll be your job to tell them.

    So without further ado, here are some highly recommended sections to include in pen test reports.

    • A Cover Sheet. This may seem obvious, but the details that should be included on the cover sheet can be less obvious. The name and logo of the testing company, as well as the name of the client should feature prominently. Any title given to the test such as “internal network scan” or “DMZ test” should also be up there, to avoid confusion when performing several tests for the same client. The date the test was performed should appear. If you perform the same tests on a quarterly basis this is very important, so that the client or the client’s auditor can tell whether or not their security posture is improving or getting worse over time. The cover sheet should also contain the document’s classification. Agree this with the client prior to testing; ask them how they want the document protectively marked. A penetration test report is a commercially sensitive document and both you and the client will want to handle it as such.
    • The Executive Summary. I’ve seen some that have gone on for three or four pages and read more like a Jane Austen novel than an abbreviated version of the report’s juicy bits. This needs to be less than a page. Don’t mention any specific tools, technologies or techniques used, they simply don’t care. All they need to know is what you did, “we performed a penetration test of servers belonging to X application”, and what happened, “we found some security problems in one of the payment servers”. What needs to happen next and why “you should tell someone to fix these problems and get us in to re-test the payment server, if you don’t you won’t be PCI compliant and you may get a fine”. The last line of the executive summary should always be a conclusion that explicitly spells out whether or not the systems tested are secure or insecure, “overall we have found this system to be insecure”. It could even be just a single word.

    A bad way to end an executive summary: “In conclusion, we have found some areas where security policy is working well, but other areas where it isn’t being followed at all. This leads to some risk, but not a critical amount of risk.”

    A better way: “In conclusion, we have identified areas where security policy is not being adhered to, this introduces a risk to the organization and therefore we must declare the system as insecure.”

    • Summary of Vulnerabilities. Group the vulnerabilities on a single page so that at a glance an IT manager can tell how much work needs to be done. You could use fancy graphics like tables or charts to make it clearer – but don’t overdo it. Vulnerabilities can be grouped by category (e.g. software issue, network device configuration, password policy), severity or CVSS score –the possibilities are endless. Just find something that works well and is easy to understand.

    • Test Team Details. It is important to record the name of every tester involved in the testing process. This is not just so you and your colleagues can be hunted down should you break something. It’s a common courtesy to let a client know who has been on their network and provide a point of contact to discuss the report with. Some clients and testing companies also like to rotate the testers assigned to a particular set of tests. It’s always nice to cast a different set of eyes over a system. If you are performing a test for a UK government department under the CHECK scheme, including the name of the team leader and any team members is a mandatory requirement.
    • List of the Tools Used. Include versions and a brief description of the function. This goes back to repeatability. If anyone is going to accurately reproduce your test, they will need to know exactly which tools you used.

    • A copy of the original scope of work. This will have been agreed in advance, but reprinting here for reference purposes is useful.
    • The main body of the report. This is what it’s all about. The main body of the report should include details of all detected vulnerabilities, how you detected the vulnerability, clear technical expiations of how the vulnerability could be exploited, and the likelihood of exploitation. Whatever you do, make sure you write your own explanations, I’ve lost count of the number of reports that I’ve seen that are simply copy and paste jobs from vulnerability scanner output. It makes my skin crawl; it’s unprofessional, often unclear and irrelevant. Detailed remediation advice should also be included. Nothing is more annoying to the person charged with fixing a problem than receiving flakey remediation advice. For example, “Disable SSL version 2 support” does not constitute remediation advice. Explain the exact steps required to disable SSL version 2 support on the platform in question. As interesting as reading how to disable SSL version 2 on Apache is, it’s not very useful if all your servers are running Microsoft IIS. Back up findings with links to references such as vendor security bulletins and CVE’s.

    Getting the level of detail in a report right is a tricky business. I once wrote a report that was described as “overwhelming” because it was simply too detailed, so on my next test I wrote a less detailed report. This was subsequently rejected because it “lacked detail”. Talk about moving the goalposts. The best thing to do is spend time with the client, learn exactly who the audience will be and what they want to get out of the report.

    Final delivery.

    When a pilot lands an airliner, their job isn’t over. They still have to navigate the myriad of taxiways and park at the gate safely. The same is true of you and your pen test reports, just because its finished doesn’t mean you can switch off entirely. You still have to get the report out to the client, and you have to do so securely. Electronic distribution using public key cryptography is probably the best option, but not always possible. If symmetric encryption is to be used, a strong key should be used and must be transmitted out of band. Under no circumstances should a report be transmitted unencrypted. It all sounds like common sense, but all too often people fall down at the final hurdle.

    Share