Sunday, March 31, 2019
Sunday, March 24, 2019
Sunday, February 17, 2019
List of Information Security Vulnerabilities
The Big List of Information Security Vulnerabilities
posted by John Spacey, June 27, 2016Information security vulnerabilities are weaknesses that expose an organization to risk. Understanding your vulnerabilities is the first step to managing risk.
Employees
1. Social interaction2. Customer interaction
3. Discussing work in public locations
4. Taking data out of the office (paper, mobile phones, laptops)
5. Emailing documents and data
6. Mailing and faxing documents
7. Installing unauthorized software and apps
8. Removing or disabling security tools
9. Letting unauthorized persons into the office (tailgating)
10. Opening spam emails
11. Connecting personal devices to company networks
12. Writing down passwords and sensitive data
13. Losing security devices such as id cards
14. Lack of information security awareness
15. Keying data
Former Employees
1. Former employees working for competitors2. Former employees retaining company data
3. Former employees discussing company matters
Technology
1. Social networking2. File sharing
3. Rapid technological changes
4. Legacy systems
5. Storing data on mobile devices such as mobile phones
6. Internet browsers
Hardware
1. Susceptibility to dust, heat and humidity2. Hardware design flaws
3. Out of date hardware
4. Misconfiguration of hardware
Software
1. Insufficient testing2. Lack of audit trail
3. Software bugs and design faults
4. Unchecked user input
5. Software that fails to consider human factors
6. Software complexity (bloatware)
7. Software as a service (relinquishing control of data)
8. Software vendors that go out of business or change ownership
Network
1. Unprotected network communications2. Open physical connections, IPs and ports
3. Insecure network architecture
4. Unused user ids
5. Excessive privileges
6. Unnecessary jobs and scripts executing
7. Wifi networks
IT Management
1. Insufficient IT capacity2. Missed security patches
3. Insufficient incident and problem management
4. Configuration errors and missed security notices
5. System operation errors
6. Lack of regular audits
7. Improper waste disposal
8. Insufficient change management
9. Business process flaws
10. Inadequate business rules
11. Inadequate business controls
12. Processes that fail to consider human factors
13. Overconfidence in security audits
14. Lack of risk analysis
15. Rapid business change
16. Inadequate continuity planning
17. Lax recruiting processes
Partners and Suppliers
1. Disruption of telecom services2. Disruption of utility services such as electric, gas, water
3. Hardware failure
4. Software failure
5. Lost mail and courier packages
6. Supply disruptions
7. Sharing confidential data with partners and suppliers
Customers
1. Customers access to secure areas2. Customer access to data (ie. customer portal)
Offices and Data Centers
1. Sites that are prone to natural disasters such as earthquakes2. Locations that are politically unstable
3. Locations subject to government spying
4. Unreliable power sources
5. High crime areas
6. Multiple sites in the same geographical location
Monday, February 11, 2019
Public Key Cryptography
PKI for busy people
Public-key infrastructure (PKI) is an umbrella term for everything that has to do with certificate and key management.This is a quick overview of the important stuff.
Public-key cryptography
Public-key cryptography involves a key pair: a public key and a private key. Each entity has their own. The public key can be shared around, the private key is secret.They allow doing two things:
- Encrypt a message with the public key, decrypt it with the private key
- Sign a message with the private key, verify it with the public key
In practice, public-key cryptography can be slow. That’s why nearly all protocols (such as TLS or SSH) only use it for authentication. Much faster symmetric-key algorithms (such as AES) are then used for encryption. This requires a shared secret, which is usually agreed upon using some flavor of Diffie-Hellman.
Hashing
Hashing algorithms (such as SHA) are one-way functions that take any input and compute a unique fixed-size output. The output is called a hash (or sometimes digest).Signatures
Signatures authenticate messages. Here’s a rough simplification:- To sign a message, a code (the “signature”) is a calculated using the message and a private key
- Using the public key and the original message, anyone can then verify the signature was indeed calculated from the message using the corresponding private key
Certificates
A certificate is a name and public key bound by a signature. It identifies the owner of a public key.The signee is called a certificate authority (CA). The CA is often some big company, like GeoTrust or Let’s Encrypt. With internal PKI, it can be any entity that nodes have been configured to trust.
A CA’s certificate can be signed by another CA, and so on. The last certificate in the chain is called a root certificate. Root certificates are trusted and stored locally. They’re usually shipped along browsers and the OS.
Formats
Most often when people talk about certificates, they refer to X.509. It’s a flexible format for representing certificates. X.509 is used by TLS, which is used by a lot of things, like HTTPS and Kubernetes.X.509 certificates are written in the ASN.1 notation. The ASN.1 is usually serialized into DER. Since binary data can be a pain to transmit, it’s often further encoded into PEM. PEM is essentially just Base64-encoded DER.
Verification
Certificate verification consists of making sure the certificate chain is valid and leads to a trusted root certificate.Of course, it assumes we trust the CAs, safe in the knowledge that they conform to sane security practices and only issue certificates to verified entities.
Bundling
Since verification requires the complete chain, certificates are often distributed as a bundle. In the case of TLS, the chain is sent during the handshake.Usually PEM files are just con
catenated into one.Certificates can also be bundled using PKCS #12 (also known as PFX) or PKCS #7. The main difference is PKCS #12 can store private keys.
Issuance
When applying for a certificate:- The client sends a certificate signing request (CSR) to the CA. It includes the client’s public key and a bunch of distinguished name attributes (such as country and domain name)
- If everything looks good, the CA generates a certificate from the CSR
For more thorough vetting, there’s also Organization Validation (OV) and Extended Validation (EV). OV implies DV and verifying ownership of the legal entity. EV is the slowest and most rigorous of all, based on CA/Browser Forum guidelines. EV certificates are usually displayed prominently (for example, on Safari the URL will be green).
For internal PKI, you can do whatever works best. With Kubernetes, you might send certificates to the nodes manually, or automate client CSRs and signing.
Revocation
There’s basically two ways to revoke certificates: certificate revocation lists (CRLs) and OCSP. A CRL is just a big list of certificates revoked by the CA. OCSP is a protocol that allows inquiring about a specific certificate.Both have their flaws. They add overhead. A lot of software don’t care. It might be easier to just use short-lived certificates and make issuance super smooth and simple.
Summary
- With someone’s public key, we can verify their signatures and send them encrypted messages
- With our private key, we can sign messages and decrypt messages sent to us
- Certificates identify public key owners
- We trust a certificate because we trust the CA that signed it
- We trust the CA because Apple/Google/Microsoft/whoever added the CA’s certificate on the server/etc. trusts them
Subscribe to:
Posts (Atom)