Key Points

risk assessments to focus security investments for highest returns

Resources

Key Concepts

Identity management (IDM) represents the management of individual identities, their authorization, roles and privileges, the authentication, in or over the system and enterprise limits with a purpose of improving security and productivity and while minimizing cost, downtime, and monotonous tasks.

OWASP Web Security project

https://www.owasp.org/index.php/Main_Page

PKI Basic Concepts

Another security measure is the use of cryptography to create two unique keys, which are large alphanumeric strings that enable users to interact in a secure way:

• A public key contains a large numerical value that is used to encrypt data to be read by the holder of the matching private key. The public key can decrypt the data encrypted by the private key holder
• A private key is mathematically linked to a corresponding public key.
• A transaction that is encrypted with a specific public key can only be decrypted by its corresponding private key—and vice-versa.
• The encrypted transaction is sent to the public address of the intended recipient, who then uses his or her own private key to decrypt the transaction.
• In addition to security, the use of private and public keys also enables users to protect their anonymity.

PKI Infrastructure Concepts

https://www.altaro.com/hyper-v/public-key-infrastructure/#1

quick table of contents if you want to skip to a certain section.

1. 1. What is Public Key Infrastructure (PKI)
   2. The Core Use of PKI and Certificates
   3. A Very Brief Introduction to Digital Encryption
      1. Encoding and Encryption Ciphers
      2. Keyed Encryption Ciphers
      3. Symmetric Encryption
      4. Asymmetric Encryption
   4. PKI Identification
   5. The PKI Certificate Issuance Process
   6. The PKI Certificate Validation Process
      1. Why Not Contact the Certification Authority During Validation?
   7. The PKI Certificate Revocation Process
   8. PKI Identity Verification Visualization
   9. Certificate Signing Operations
   10. SSL Encrypted Communications
   11. Offline Certification Authority
       1. The Risks of an Online Root Certification Authority
       2. Offline CA Creation Process
       3. An Offline CA Without a CRL
   12. What IS a Certification Authority?
       1. Does a Certification Authority Require a CRL?
   13. The Dangers of Self-Signed Certificates
   14. Going Further with PKI

A public key infrastructure or PKI establishes a digital trust hierarchy in which a central authority securely verifies the identity of objects. We commonly use PKI to certify users and computers. It functions by maintaining, distributing, validating, and revoking SSL/TLS certificates built from the public key of public/private key pairs.

There are many associated terms connected to public key infrastructure you’ll need to be familiar with so I’ll lay them out here. You don’t necessarily need to memorize these, or even understand all of them at this stage – you might even want to skim or even skip this section and just use it as a reference later. I have deliberately kept these descriptions simple to stay within the scope of the article.

• SSL: “SSL” stands for “Secure Sockets Layer”. SSL was designed to secure digital communications traveling over insecure channels. TLS has supplanted SSL, but we still use the term SSL, mostly for familiarity reasons. It has cemented itself into the common vernacular, so there’s little use in fighting it. After this point, I will use “SSL” in its generic sense.
• TLS: “TLS” stands for “Transport Layer Security”. This technology group serves the same fundamental purpose as SSL and depends upon the same basic components and concepts, but the technologies cannot be used interchangeably.
• Cipher: an algorithm used for encoding or encryption. In SSL, the term often refers to a collection, or “suite” of ciphers, each with a different purpose in an SSL conversation.
• Key: A digital key used with SSL/TLS is just a sequence of bits, usually expressed in hexadecimal characters. Ciphers use keys to encrypt and decrypt data. Keys used in standard PKI are expected to be a certain number of bits, a power of 2 starting at 1024 (ex: 2048, 4096, etc.). A longer key provides stronger defense against brute-force cracking when used in a cipher, but also requires more computing overhead. In PKI, keys come in pairs:
  • Private key: a key that is held by its owner and never shared with anyone else. The private key in a private/public pair is the only key that can be used to decrypt data that was encrypted by the public key. A private key that is accessed by anyone other than its owner is considered “compromised”.
  • Public key: a key that can be shared with anyone. The public key in a private/public pair is the only key that can be used to decrypt data that was encrypted by the private key. The “PK” in “PKI” comes from its usage of public keys. It also serves as a reminder: we use “public key” in PKI but never “private key”, because no private key should ever enter the infrastructure.
• Certificate: A certificate is a digital file used for identity and authorization. You will often see these referred to as “SSL certificates”. However, SSL implies communications, whereas certificates have more purposes. The term has lodged itself in common jargon, so it too will continue despite its technical inaccuracy. When I remember, I say “PKI certificate” instead.
  Certificates contain many components. Some of these items:

  
  

  • Identifying information. There are several defined fields, and most certificates contain only a subset. Examples:
    • Common Name: The name of the object that the certificate identifies. Sometimes that is a fully qualified domain name, such as www.altaro.com. Sometimes, it is just a name, such as “Eric Siron”.
    • Locality: The city, or equivalent, of the entity represented by the certificate
    • Organization: The name of the organization that owns the certificate
  • A public key
  • Validity period
• Encoding: Passing data through an algorithm to transform it for the purpose of facilitating a process or conforming to a standard. For instance, base-64 encoding can turn character string sequences from a human-readable form that might cause problems for simple string handlers (like URLs) into strings that computers can easily process but humans would struggle with. Text can be encoded in UTF8 (and others) so that it fits a common standard. “Decoding” is a convenience term that we use to mean “reversing encoding”, although it could be argued that there is no such thing. We simply perform a different encoding pass on the new data that generates output that matches the original data. The most important thing to understand: encoding does not provide any meaningful security. We only use encoding for convenience.
• Encryption: Encryption is similar to encoding, but uses algorithms (usually called ciphers in this context) to obscure the data as opposed to adapting it for a functional purpose. “Decryption” reverses encryption.
• Cracking: a term that traces its origins to the same concepts behind physical-world activities such as “cracking a safe”. It refers to the action of decrypting data without having access to the private key. I previously mentioned “brute-force” cracking, which means trying all possible keys one at a time until finding the correct one. I’ll leave further research on other techniques to you.
• Certification Authority: Sometimes shortened to “certificate authority”. Often abbreviated to “CA”. An entity that signs and revokes certificates.
• Self-signed certificate: A certificate in which the identity represented by the certificate also signed and issued the certificate. The term “self-signed” is often used erroneously to describe a PKI that an organization maintains internally. A certificate signed by any authority other than the certificate holder is not self-signed, even if that authority is not reachable on the public Internet or automatically trusted by computers and devices.
• Root Certification Authority: The top-most entity of the PKI, and the only entity that expects others to blindly trust it. Uses a self-signed certificate. Can sign, issue, and revoke certificates.
• Intermediate Certification Authority: Sometimes referred to as a “subordinate CA”. A  CA whose certificate was signed and issued by another CA. Generally identical in function to a root CA, although the root or a superior intermediate CA can place restraints on it.
• Certificate chain: a single unit that contains all of the information needed to trace through all intermediate CAs back to and including the root CA.
• Server certificate and client certificate: technically incorrect, yet commonly used terms. In typical usage, these terms mean “the certificate used by the server in a given SSL communication” and “the certificate used by the client in a given SSL communication”, respectively. However, you cannot correctly say, “this certificate file is a client certificate”. “Server” and “client” are arbitrary designations for a digital transmission and have no meaning whatsoever when you’re only referring to a single entity (the certificate holder). A certificate is a certificate.
• Constraints, key usage, and enhanced key usage: actions that a CA has authorized the certificate holder to perform. For instance, consider a development application that uses a private key to sign a piece of code. If the CA has signed the matching certificate for code signing usage, then a computer that runs that code and trusts the CA will treat the code as properly signed. However, a private key can be used for any purpose — constraints only limit the actions the issuing certification authority will validate. That means that you still cannot correctly refer to a certificate with the Client Authentication key usage as a “client certificate”.
• Certificate Revocation List (CRL): A list of certificates that the CA has marked invalid. If a certificate appears on this list, then no client should consider it reliable. The CA signs the CRL to make it tamper-proof so that it can be freely distributed and trusted.
• Online Certificate Status Protocol responder (OCSP responder): CRL’s are just simple lists. A client must download the entire CRL and search through it to check on any given certificate. For very long CRLs and/or low-powered clients, that can take a lot of time. An OCSP responder keeps a copy of the revoked certificate list and can perform the search for any client that asks.

Other CA concepts

Certification Authority (CA)

A CA issues certificates to and vouches for the authenticity of entities. The level of trust you can assign to a CA is individual, per CA, and depends on the CAs Policy (CP) and CA Practices Statement (CPS).

RootCA

A RootCA has a self-signed certificate and is also called Trusted Root. Verification of other certificates in the PKI ends with the RootCAs self-signed certificate. Since the RootCAs certificate is self-signed it must somehow be configured as a trusted root for all clients in the PKI.

SubCA

A subordinate CA, or SubCA for short, is a CA whose certificate is signed by another CA, that can be another SubCA or a RootCA. Since the SubCAs certificate is signed by another CA, it does not have to be configured as a trusted root. It is part of a certificate chain that ends in the RootCA.

Registration Authority (RA)

An RA is an administrative function that registers entities in the PKI. The RA is trusted to identify and authenticate entities according to the CAs policy. There can be one or more RAs connected to each CA in the PKI.

Validation Authority (VA)

A VA is responsible for providing information on whether certificates are valid or not. There can be one or more VAs connected to each CA in the PKI.

End-entity

An end-entity is a user, such as an e-mail client, a web server, a web browser or a VPN-gateway. End-entities are not allowed to issue certificates to other entities, they make up the leaf nodes in the PKI.

Authentication Services

CORS - Cross site Origin Resource Sharing

https://www.codecademy.com/articles/what-is-cors

same origin policy

The same-origin policy is very restrictive. Under this policy, a document (i.e., like a web page) hosted on server A can only interact with other documents that are also on server A. In short, the same-origin policy enforces that documents that interact with each other have the same origin.

Cross-origin requests, however, mean that servers must implement ways to handle requests from origins outside of their own. CORS allows servers to specify who (i.e., which origins) can access the assets on the server, among many other things.

You can think of these interactions as a building with a security entrance. For example, if you need to borrow a ladder, you could ask a neighbor in the building who has one. The building’s security would likely not have a problem with this request (i.e., same-origin). If you needed a particular tool, however, and you ordered it from an outside source like an online marketplace (i.e., cross-origin), the security at the entrance may request that the delivery person provide identification when your tool arrives.

Single Sign-on Concepts

Single sign-on (SSO) is a method of access control that enables a user to log in once and gain access to the resources of multiple software systems without being prompted to log in again. Single sign-off is the reverse process whereby a single action of signing out terminates access to multiple software systems.

How SSO works

Kerberos authentication servers manage a resource pool for authentication ids

With SSO, there is a TGT - ticket granting server - that all users authenticate to.

The TGT grants tickets to a user request to access specific servers automatically providing authentication

user only authenticates once to the TGT authn server

OAuth2 - delegate resource rights to another app

OAuth2 access protocol for a remote resource from a web site

1. create an access token to a resource with specific rights ( eg view not update )
2. send the access token to a client
3. the access token stored in the app's page header
4. when a client requests the app resource, the server issues a redirect request to the resource server providing the access token
5. no user id or password from the resource server is exposed

OAuth2 overview - youtube

compare Oauth2 and Openid

compare oauth2 and openid - 1 hr - youtube

Zero-Trust Security Model for Microservices

https://drive.google.com/open?id=1f7OGCWYKLrLDU6_UPMJNfGivdQ0Ec8de

to implement a zero-trust model, security and operations teams willneed to focus on two key concepts. First, security will need to be integrated into the workloads themselves, and will move with the instances and data as they migrate between internal and public cloud environments. Second, the actual behavior of the applications and services running on each system will need to be much better understood, and the relationships between systems and applications will need more intense scrutiny than ever to facilitate a highly restricted, zero-trust operations model.

Sailpoint Identity Management

With the latest release of IdentityNow and IdentityIQ 8.0, SailPoint continues to be laser-focused on helping organizations of all sizes to govern smart with SailPoint Predictive Identity while continuing to govern all and to govern deep in the following ways:

• Govern Smart with SailPoint Predictive Identity by delivering a recommendations-based approach to identity that speeds identity decisions, evolving identity programs to be more dynamic, adaptive and predictive
• Govern All by ensuring that all users and their access is appropriate for their role and current access needs, with enhanced capabilities that automatically shut-down lingering access that could result in unnecessary risk; and by extending governance of data stored in files to include sensitive data that is embedded in image files
• Govern Deep by simplifying and streamlining access policies. For example, creating separation-of-duties (SoD) policies now takes a matter of minutes versus weeks, dramatically improving operational efficiency and security.

Secure Email setups S/MIME

https://support.google.com/a/answer/6374496?hl=en

HMAC - Hashed Message Authentication Code - alternative to PKI signed messages

https://en.wikipedia.org/wiki/HMAC

In cryptography, an HMAC (sometimes expanded as either keyed-hash message authentication code or hash-based message authentication code) is a specific type of message authentication code (MAC) involving a cryptographic hash function and a secret cryptographic key. As with any MAC, it may be used to simultaneously verify both the data integrity and authenticity of a message.

HMAC can provide authentication using a shared secret instead of using digital signatures with asymmetric cryptography. It trades off the need for a complex public key infrastructure by delegating the key exchange to the communicating parties, who are responsible for establishing and using a trusted channel to agree on the key prior to communication.

Opportunities

risk assessments to focus highest security investment returns

companies are starting to strengthen their business and technology environments with quantitative risk analytics so they can make better, fact-based decisions. This has many aspects. It includes sophisticated employee and contractor segmentation as well as behavioral analysis to identify signs of possible insider threats, such as suspicious patterns of email activity. It also includes risk-based authentication that considers metadata—such as user location and recent access activity—to determine whether to grant access to critical systems. Ultimately, companies will start to use management dashboards that tie together business assets, threat intelligence, vulnerabilities, and potential mitigation to help senior executives make the best cybersecurity investments. They will be able to focus those investments on areas of the business that will yield the most protection with the least disruption and cost.

Challenges

Solutions

Cryptography Libraries Compared - wikipedia

https://en.wikipedia.org/wiki/Comparison_of_cryptography_libraries 

CA Mgt tools

Openssl - an open-source certificate administration CLI

https://www.openssl.org/

https://www.openssl.org/docs/

https://www.openssl.org/docs/OpenSSLStrategicArchitecture.html

Portecle - open CA Mgt tool - runs in browser w Java Web start ( used by Jira etc )

http://portecle.sourceforge.net/

Portecle is a user friendly GUI application for creating, managing and examining keystores, keys, certificates, certificate requests, certificate revocation lists and more.

Features

Currently, Portecle can be used to, for example:

• Create, load, save, and convert keystores.
• Generate DSA and RSA key pair entries with self-signed version 1 X.509 certificates.
• Import X.509 certificate files as trusted certificates.
• Import key pairs from PKCS #12 and PEM bundle files.
• Clone and change the password of key pair entries and keystores.
• View the details of certificates contained within keystore entries, certificate files, and SSL/TLS connections.
• Export keystore entries in a variety of formats.
• Generate and view certification requests (CSRs).
• Import Certificate Authority (CA) replies.
• Change the password of key pair entries and keystores.
• Delete, clone, and rename keystore entries.
• View the details of certificate revocation list (CRL) files.

Resources

For downloads, contact information and mailing lists, issue tracking and other development facilities, see the SourceForge.net project page. Check also your operating system distribution to see if Portecle is already included. RPM packages of Portecle are additionally available from the JPackage Project.

Portecle can be launched directly with Java Web Start (Java 1.7 or later with Web Start required):

http://portecle.sourceforge.net/

Portecle's Web Start files are self-signed. Security settings in some environments do not allow such Web Start applications to run by default. If an error message indicating this scenario is presented and you want to work around it, one way is to add http://portecle.sourceforge.net/webstart/portecle.jnlp to Java's exception site list.

Documentation

Take the tour. Read the HOWTOs.

http://portecle.sourceforge.net/howtos.html

• Create a new keystore
• Open an existing keystore
• Save a keystore
• Save a keystore with a different name
• Change a keystore's type
• Set a keystore's password
• Produce a keystore report
• Generate a key pair
• Examine a certificate file
• Examine an SSL/TLS connection
• Examine a certification request file
• Examine a CRL file
• Import a trusted certificate
• Import a key pair
• Delete a keystore entry
• Export a keystore entry
• Rename a keystore entry
• Examine a keystore entry's certificate
• Clone a keystore key pair entry
• Set a keystore key pair entry's password
• Generate a CSR for a keystore key pair entry
• Import a CA reply into a keystore key pair entry
• Use a CA certs keystore

EJBCA - open CA mgt tools community edition

https://www.ejbca.org/

EJBCA covers all your needs – from certificate management, registration and enrollment to certificate validation.

Welcome to EJBCA – the Open Source Certificate Authority. EJBCA is one of the longest running CA software projects, providing time-proven robustness and reliability. EJBCA is platform independent, and can easily be scaled out to match the needs of your PKI requirements, whether you’re setting up a national eID, securing your industrial IOT platform or managing your own internal PKI.

https://download.primekey.com/docs/EJBCA-Enterprise/6_15_2/EJBCA_Documentation.html

EJBCA features

EJBCA Architecture Options

There are multiple ways that you can implement and architect a PKI solution, ranging from simple and low cost, to very complex and costly. EJBCA allows implementing virtually any type of PKI architecture and the following sections describe a selection of common PKI architectures deployed:

• Single CA/RA

• CA with Distributed RAs

• External RA, only Outgoing Connections

• Off-line Root CA and Multiple Sub CAs

• Validation Authority

• Enterprise Integration

• Cluster and High Availability

• Hybrid PKI with Public Cloud

• Audited Operations

• Automated and Large Scale Operations

• Software or Appliance, Virtual or Physical

EJBCA Internal Architecture

OpenXPKI - open source CA Mgt tools

https://www.openxpki.org/

OpenXPKI is an enterprise-grade PKI/Trustcenter software. It implements the necessary features to operate a PKI in professional environments. While primarily designed to run as an online RA/CA for managing X509v3 certificates, its flexibility allow for a wide range of possible use cases with regard to cryptographic key management.

OpenXPKI has a stable, mature code base and a growing user base. The developer team actively supports several professional installations some of which have been running continuously since 2009 and host several logical CAs with hundreds of thousands of active certificates.

Core features

• WebUI compatible with all major browsers
• Ready-to-run example config included
• Support for SCEP (Simple Certificate Enrollment Protocol) and EST (Enrollment over Secure Transport)
• Native Microsoft Windows auto-enrollment supported via 3rd party software
• Easy adjustment of workflows to custom needs
• Run multiple separate CAs with a single installation, automated rollover of CA generations
• Can use Hardware Security Modules (e. g. Thales HSMs) for crypto operations
• Issue certificates with public trusted CAs (e. g. SwissSign, Comodo, VeriSign)
• Based on OpenSSL and Perl, runs on most *nix platforms
• Feature complete OpenSource community edition
• Commercial support and training, professional services and advanced enterprise features are available
• check out the roadmap for planned features

Resources

• Development and issue tracking using github
• Mailing lists for users and developer
• Documentation (some) at ReadTheDocs
• Package repository at https://packages.openxpki.org/ (Debian Jessie).
• FreeBSD Ports Repository https://www.freshports.org/security/p5-openxpki/
• Community support is availble via the OpenXPKI users mailinglist

OpenXPKI Quickstart Guide

https://openxpki.readthedocs.io/en/latest/quickstart.html

No Ubuntu packages available

XCA - simple CA mgt using Openssl

https://sourceforge.net/projects/xca/

X Certificate and Key management is an interface for managing asymetric keys like RSA or DSA. It is intended as a small CA for creation and signing certificates. It uses the OpenSSL library for the cryptographic operations.

Please see the XCA homepage http://hohnstaedt.de/xca

Digicert - open source Windows CA tool

https://www.digicert.com/util/

The free DigiCert Certificate Utility for Windows is an indispensable tool for administrators and a must-have for anyone that uses SSL Certificates for Websites and servers or Code Signing Certificates for trusted software.

Details

Next Steps

Related articles

Link

• Page:
  m Consulting Process
• Page:
  Web CMS
• Page:
  m Marketing Services Plan
• Page:
  t Test Confluence plugins
• Page:
  a Confluence admin

Instructions - Move sites between Confluence instances

1. How to Export a Space in Confluence Cloud to xml zip file
2. How to Import a Space in Confluence Cloud from xml zip file