Content management error: Header Banners should not be placed in the Navigation placeholder!
Content management error: Generic Content Banners should not be placed in the Navigation placeholder!
Once upon a time, just knowing a secret passphrase or a secret handshake was sufficient. The phone Phreakers of the 1950s knew that just making a 2600 Hz sound into a telephone would yield extended access and possibly free telephone calls. Over time, these systems have modified, but attempts to get free rides continues.
Today, access management is still just as important — be that in Operational or Information technology environments. And while currently we use modern encryption ciphers such as AES-256 1, encryption negotiation protocols such as TLS 1.2, and X509 certificate signing algorithms such as SHA256 with RSA, it is pretty clear that we will be shifting over time to even stronger implementations. This may sound alien, but your web browser you are using right now just did all this for you; and it decided to show you a green padlock (or similar) — because in the eyes of the browser vendor (Chrome, Firefox, IE, Opera, Safari, Lynx 2, Links 3) felt this was sufficiently secure (complex) to protect you at this time.
Content management error: Generic Content Banners should not be placed in the Navigation placeholder!
To highlight this, we have recently been looking at getting a digital fingerprint on documents being passed around between integration partners. These files (such as PDFs, MS Word Docs, images, etc) may be subjected to a "hash" or "digest" to give a sort of fingerprint. Over time there have been different algorithms used to implement this fingerprinting. However, one of the risks of taking a fingerprint is the chance of a "collission", where two totally different sources produce the same fingerprint.
Content management error: Generic Content Banners should not be placed in the Navigation placeholder!
For an example of fingerprint data in action, lets take the content "Hello World." and show it with a fingerprint from some legacy algorithms:
ALGORITHM | Value of hash('Hello World.')
Sometimes the output fingerprint value is the same length, but the method of fingerprinting — the order in which data is examined which modifies the output value — may make it more secure. But what is clear is that newer digests are generally producing larger checksum values.
Today, it is commonly seen as acceptable to use a SHA-256 algorithm — indeed, we are at the tail end of a multi-year migration from using SHA-1 as the signature algorithm from web site SSL certificates. I am sure that, over the course of time, we will move to a longer and stronger (more unique) fingerprint just as we see Moore's Law continue to improve compute capacity, and bandwidth continues to increase globally.
Case in point for a hash collision: an article in February 2017 from The Register shows a collission for the SHA-1 hash, but rightly concludes that the difficult (and financial cost) to doing this is dropping over time.
Content management error: Generic Content Banners should not be placed in the Navigation placeholder!
The underpinning idea is that there is a good way of doing most things today, but there are probably better ways of doing an activity in future. Cloud providers are constantly producing a better service: they employ more people than any individual company, and attract top tallent in order to produce these services. They also submit themselves to an ever growing list of compliance and certification regemes, the world over.
10 years ago (yes, a decade), EC2 Security Groups were the only protection provided by the Cloud providers for your virtual machines in the AWS EC2 environment. Other customers were on adjacent IP addresses — it was a shared (RFC1918) address space. Evolution happened and Virtual Private Cloud — your own private network — provided an extra layer of security. Then came Network Access Control Lists (NACLs), NAT Gateways and Egress-Only Internet Gateways (for IPv6 VPC networks). Multi-factor authentication for console sign on, IAM Policy and Policy Conditions, S3 Endpoints for VPC and Endpoint Policies, DynamoDB Endpoints for VPC, etc. None of this stood still, and keeping current on the improving capabilities is itself a challenge (and for us, a passion).
We were recently asked to do a security assessment of a new AWS Cloud workload for a State Government agency that handles large volumes of financial transactions. Modis's an Enterprise-wide AWS Cloud security assessment (itself 2 pages), and a per-workload (per AWS Account) security checklist (10 pages at the time), makes a comprehensive assessment for security and operational considerations.
The purpose of this was two-fold: one to assertain what had been done already, but also to act as discussion points around the decisions and design of the workload from a security and operational perspective. However, we are not done, and in just a few months, this has grown again: there are more recommendations that we look at to further improve security and ease the operational management over time.
During this exercise, the customer's development and operations team members were engaged to think through their deployment from the lens of security and operations, while afterwards we wrote up the recommendations and findings and returned this to the customer for their consideration and implementation.
We now operate this with multiple Public Sector and commercial customers across the country — a one or two day assessment done with the security and operational teams (or just their team leads) to help reduce the risk in making changes to running environments.
Of course, we are constantly updating our checklists to keep track of current capabilities, and we know the future will be even richer in the controls and capabilities our customers may make use of.
We find that various customers have varying security and operational knowledge and experience, and it is our pleasure to bring a fresh perspective to these organisations to assist them on their cloud journey. Obviously there are many things we look at, including such embarrassing issues as leaving private data publicly accessible — such as the recent article about millitary contractors doing so with AWS S3, or preivous articles such as the CloudPets failure. These are mistakes that should be prevented by having polcies in place — and should routinely be verified to ensure they are still in place.
Content management error: Generic Content Banners should not be placed in the Navigation placeholder!
Content management error: Generic Content Banners should not be placed in the Navigation placeholder!