The Cyber-Landscape In 2021 – Does Zero-Trust Fit?

Having spent over 36 years in an industry, now entitled Cyber, starting my cyber-career post completing formal IT Security Training at the Police, School at RAF Newton, I went on to work in the world of Counter Intelligence where I took up an enhanced vetted post in the SIGIN/COMINT world, moving on to a role of IT SyO within an Accredited (Verified Trust) US Agency SCIF (Sensitive Compartmented Information Facility) who engaged in areas such as Talent Keyhole (TK-SAT-COM), and many other specialised support projects provisioned, ranging from Lockerbie, to Jamie Bulger case. Post my 22 years Royal Air Force Service, I went on to work with multiple global companies, including big name brands such as General Motors, Logica, Experian, BEA, T5, Government Departments and Agencies, The Houses of Parliament, Banks (e.g., NAG and Challenger Banks), and multiples of SME’s, hence, by background is both horizontal and vertical across multiple domains. – and with the exception of some SME’s (as reflected by the on-line survey statistics below), in every single case, when these organisations have had need to connect their infrastructure into another unknown domain, or service – one thing has been for certain – they have always verified that the connection is required, secure (as far as known), and have always verified the associated provenance – I can’t personally recall any such occasion when any such an organisation knowingly connected to another network of service on a just-do-it basis basis. In other words, they always verified the connection prior to trusting the end-client or server. Meaning they did not trust anything until such time that point of interface was considered trustworthy! And recalling that UK Government and other such Agencies have taken the Code of Connection (CoCo) approach, we can further demonstrate the historic fact that any form of connection from A to B had to be verified and agreed prior to being established – AKA Trusted – more on CoCo and trust later. When it comes to the SME however, depending on the type of business, I have discovered them to be of varying postures when it comes to any form of Digital Security, and have on multiple occasions observed, and have stopped the establishment of a trust-relationship, when in fact such a connection would have been adverse to the interest of the overall security posture – which is possibly why so many SME’s fall so easily to the trending Ransomware attacks!

Fig 1 – The Potentials of unmanaged security postures

This introduction takes us directly into the conversation about the latest cyber buzz word to enter the dictionary of security, being the snake-oiled commercial mythical opportunity for the next-best fix for all cyber-ills presented by the growing and demerging cyber threats – enter Zero-Trust (ZT). First, let us consider what the scope of ZT is bringing to the table – it is of course suggesting that all is untrusted, until that is, we arrived at a juncture which confirms that trust has been established. In other words, prior to allowing the connection, the proposed trust-relationship between the two points (or more) have been verified, and thus the connection may proceed based on the Due Diligence which was carried out to verify the level (or not) of trust – thus, not so much a case of ZT, but VT (Verified-Trust). See statistic drawn from the on-line survey below, which infers that in the great scheme of security, we have, and are practicing an approach based on ZT already in most cases.

Fig 2 – ZT – Nothing new

I did mention in the introduction the UK Governments employment of the CoCo approach which is used to underpin a trust relationship between two, or more parties prior to allowing connectivity to be established. The CoCo approach also sets out several areas of criteria to which the interfacing party must agree, and as such concerned Government Agency will trust any agreement(s) which have been put in place under the obligations of the CoCo and the associated contract – in other words, once the mandated obligations of connectivity have been agreed, the Government Agency will trust that relationship. However, notwithstanding the level of trust bestowed on the associated party does not always hold true. In one case I have observed, a well-known provider of support services to UK Government entered into such a CoCo/Contract agreement with a Sensitive UK Government Agency to host a Sensitive Service. In this arrangement the CoCo had mandated several obligations, one of which was the importance to not host said service in any global location which was considered inimical to the public and security interest of the state (UK). However, notwithstanding the agreement to the mandated CoCo, said company had somehow manged to wrongly deploy the sensitive service into what was recognised as a known hostile location – and when the incumbent CISO was alerted to the exposure, they failed to act, and as far as I can recall that deployment into the hostile region remained extant – it’s this what we understand to be trust?

Note 1 – on Humans: No matter the style of the adopted security methodology, be it Zero-Trust, Verified-Trust, or Valhalla, so long as people are involved in the line of the security processes (and they will of course be so for the foreseeable future), there will always be the existence of a soft point at which a vulnerability, exposure, or adverse manipulation may be introduced into the supply chain of the chosen security model – AKA, a 100% security posture is, as of 2021 not possible.

Note 2 – Artificial Intelligence (AI): There is a school of thought which considers that AI may be the solution to the woeful state of cyber-security ills. However, remembering that the human hand and mind are the initiators, or algorithms, and are thus the main providers of the machine-logic, any such decisions derived from the human orientated logic, will be potentially implicated by the imperfection of such human input – hence Note 1 above still applies.

 When we consider any such beast as the inference of ZT, we should also reflect on the trusted world of interconnected Supply Chains into which multiples of trusted endpoints were logically associated. Here, ponder for a moment on the major US information technology Company SolarWinds who suffered a successful cyberattack resulting in a compromise which went undetected for months – a cyberattack which then went on with a secondary spread on to the multiples of trusting clients, including but not limited to the likes of the elite cybersecurity firm FireEye, upper echelons of the US Government, including the Department of Homeland Security and Treasury Department – with the widespread trusted integration of SolarWinds into around 33,000 trusting clients to provision IT Support Services the implications of this particular trust-relationship should send shivers down any digital-backbone!

In fact, when we consider the world of established trust and the Third-Party supply chain, that shivering digital-backbone should take a closer look at what such trusted-relationships really mean in the real-world operational sense. In the cases of Airbus, Rolls Royce and Expelo, it isn’t uncommon to encounter a breach through and established trusted relationship. Here, consider the 2018 Opus/Ponemon Institute findings of Third-Party Security concluding that in 59% of data breaches originate in some way from the trusted relationships with Third Party Suppliers see URL below: 

https://www.businesswire.com/news/home/20181115005665/en/Opus-Ponemon-Institute-Announce-Results-2018-Third-Party

 They go on to conclude that, even with the deployed, vigorous security controls and, supposed secure postures, most organizations struggle with delivering robust security (so how will they engage a complex ZT model?). Again, it is in this area, and with the backdrop of the SolarWinds debacle, and others, it would seem hard to understand how the concept of Zero-Trust will bring value to the table of Cyber Resilience.

Given we are where we are, and that we are now accommodated with the knowledge of known-known security beaches, and all that goes with them, we must of course acknowledge that something, somewhere is, and has gone wrong. And this linked to the awareness that countries such as Saudi Arabia were upping their spend on cybersecurity defences to the tune of 6.2 percent in 2020, compared to the $400 million invested in 2019, then we must also acknowledge that there are financial commitments in play all around the globe to attempt counter the digital-evils – yet they would seem to be, even in today’s numbers, falling short of the exceptions! Again, an indication that there is a root-problem at the heart of the applied methodologies which are being delivered to harden, what would seem to be a soft-shell – will ZT solve this problem?

What has History Taught Us (Not a lot it would seem)

If we look back on the origins of Digital Defences, we will find that as the complexities of Digital Infrastructures were introduced, agencies such as CESG at Fiddlers Green, were quick of the mark to provision quality documentation in the guise of Memorandums and Manual Sets to raise the awareness of risks, and to support the deployments with a standardised, risk-based approach, examples of which are:

• CESG COMPUSEC MEMORANDUM NO: 13, Issue 3, September 1996 – Protecting Government Connections to the Internet

• CESG COMPUSEC MANUAL: N, Issue 1.0, June 1996 – Vulnerabilities of the TCP/IP Protocol Suite

When reading through these aged documents, which I still have in my possession, it is surprising just how many areas of risk which have been outlined, are still discovered in the current year 2021! Considering the advice which CESG directives outlined, I start to get a nostalgic feel for what may now be, an almost lost appreciation the Nuts-and-Bolts, technical security approach that was taken for granted, which has morphged over to the pen-and-tick approach of today’s Boot-Camp driven, Professionally Certified World – we may have missed, or forgotten a key set of skills. See Fig 3 below:

Fig 3 – Extract from CESG COMPUSEC MANUAL: N

It is here in my humble opinion where the race-to-the-bottom of the cyber security commercialised industry, and the plethora of industry led buzzwords such a Zero-Trust have missed the point and, in some cases, have misinformed, or misled the awaiting, insecure audience of expectant concerned customers. The bottom line here surely must be that:

1. We should accept that what is being delivered is falling short of the security objectives

2. We may accept that there are three types of endpoints on the Internet:

• Those who have been Hacked
• Those who will be Hacked
• And those who have been Hacked, but are unaware of the compromise

3.  No matter the vendor promises, there is no such thing as 100% security

4. That at best, all we can do is deliver some form of new approach toward delivering a security posture which is hardened from the inside out

Verified-Trust Building Blocks (AKA Back-to-Basics)

OK, so what is the concept of Verified-Trust Building Blocks, and what makes it different from other methodologies? The first difference is that it does not arrive in an over-promise wrapped package which will have end user and government rushing out to cry ‘we have the solution’ – nothing could be further from the truth. Secondly, it is not looking to deliver a solution in a box as a one-stop-shop to fix all cyber-ills as is being inferred by ZT.

Verified-Trust Building Blocks is a methodology which aims to join up all the robust areas of the known-known cyber security world, trusted applications, policies, procedures, standards and document sets, and bring them all together in a complimentary manner which hardens and manages the deployment from the inside out. Not necessary taking the Zero-Trust approach, but side stepping that into a secure supportive environment that looks to verification of trust at multiple levels, which then go on to complement each area bottom up, and top down. Of course, as with any security system, we must always keep in mind the most dangerous component of all in our operational worlds which needs to be closely managed at all levels – and this is those things covered in skin ‘People’. It may also be that, as the reader takes a closer look at what Verified-Trust is, they may feel that they are actually doing already – but if so, think again, and pull back the covers and take a closer look – see Fig 4.

Fig 4 – Overarching Approach – Use what is Known-Known Trust

Legend

Examples of Known-Known Trusts

The idea behind this methodology is to recognise what has worked over the decades we have travelled to deliver a robust cyber/digital security posture, to identify the best-of-best to underpin the security ambition, to deliver greater level of resilience to fend of those know-known cyber evils. For example, but not limited to:

1. Policy/Procedures, and Standards instruments: Here we look to apply proven underpin of proven elements, such following the FIPS-140/2 standard to deliver an assured level of Encryption, OWASP to deploy secure web environments, and the road maps of ISO/IEC Standards such as the ISO/IEC 27001 (Management of Security), ISO/IEC 27035 (Incident Management) etc. 
2. Governance and Compliance: Delivering a robust Framework which are fit for purpose in the current climate of digital threats – not just following the accepted, usual approach to supporting the internal/external Audit expectations, but to take the activities to the next level by implementing Blue, Red Teams, and following the subliminal areas which may indicate vulnerabilities and exposures through the use of, those underused OSINT (Open Source) capabilities to discover both unknown-knowns, and even more so those open unknown-unknows.
3. People: The people, AKA the Key Business Assets are also one of the most valuable Building Blocks in the overall security infrastructure which are so often not leveraged and maximised to the benefit of the overall security mission. For example, businesses fail to fully exploit the aspect of the Human Firewall by leveraging their workforce as a line of defence. On the opposing side where the failures continue to manifest in, what can amount to a failure to integrate Human Resources (HR), AKA, the People Managers into the overall security posture of the security mission, managing joiners and leavers, and those who move through the organisation – ensuring that their access rights are maintained in concert with their appointment and employment status – I like many have seen this critical Security Block break on many occasions. Here, if we need a good (bad) example, just consider the case of the ex-employee of the Kansas Water Treatment Plant who hacked the system after remotely logging in – here presenting potentially life implicating circumstances, and given remote access is one of the top five security gaps that exist in water treatment plants, this case is again standing testament to that documented exposure. But it is not just water plants, as this exposure exists in many horizontal and vertical industries – here a security exposure and vulnerability that can be better addressed by establishing a Security Building Block to interface into HR to work cross JD responsibilities to gain the common objective security. And as a final word here, given the abuse of powers as outlined above by a lady CISO, why not consider the benefits of an internal Whistle Blower Policy – it may just save your skin (or bacon)!
4. Skills: Aligned to People, it is of paramount importance that the area of skills is addressed at all levels, to ensure that the workforce are both well versed in their area of responsibilities, and to ensure they have a high level of pragmatic competence aligned to their Job Description (JD) – what that, you already do this. Then how can it be that, on so many occasions and many encounters we discover those who have not received formal training, or who are learning on-the-job. How come, we encounter multiple circumstances in which a procurement of a new system of application, does not come along with the required, commensurate level of training. In one example I have seen first-hand, a particular big-name organisation had a Digital Forensics Team who were investigating an internal report involving podophile material, without even understanding the legal ramifications – a very dangerous position to be in. And please do not mix Skills up with Certifications, as they are very different animals – granted Certifications are important but remember they do not necessarily amount to a level of skill or competence – they can, in some cases amount to the ability to respond to and satisfying a Q & A activity based on a force-fed Boot Camp. Thus, the Skills based Building Block is another integrated element which can provide a robust underpin for the organisational security posture.
5. Physicality: On occasions it can be easy to suffer from the dangers presented by Tunnel Visioning – only seeing what is in the contextual vision of the predetermined task at hand, maybe over focusing on the digital element, and ignoring other factors that are presented into the confronted landscape. One, again good (bad) example here was a massive investment made in a Data Centre situated in the East Midlands. The efforts to go into the planning were meticulous to assure the finished product would meet the expectations of a Tier 4 facility. It was unfortunate that whilst the project team were focusing on the ground of the build, they should have looked up at the roof – it was of an insufficient grade to facilitate the desired top-notch security outcome. There are many more examples of where such tunnel visioning overlooked the conjoined aspect of the physical world – thus one more Building Block to enter the Framework is that of Physicality – also known as things you can kick, lift, touch and move, and of course steal.  
6. Applications and Tech: Here we arrive at the juncture at which we may derive trust from the best-of-the-best, and other such products, and applications which have gone through independent verification to prove that they do what they say on the tin. On this topic I am talking about product initiatives such as the National Cyber Security Centres (NCSC) CAPS (Certified Assisted Products) Scheme – see: https://www.ncsc.gov.uk/section/products-services/ncsc-certification. Out of this imitative we are not only able to deploy and employ a product which has been proven (verified) to meet the outlined security objectives through rigorous and complex independent evaluation, which of course underpins the trustworthiness of the procured device or application – we also know that, by enlisting such a selected product into the overall framework of our security posture, we are, by implication, increasing the overall level of verified trust placed in the product(s) of choice. Furthermore, as an example, given iStorage have picked up on the conversation around Verified Trust, and our suggestion of a Building Blocks based security approach, we may also consider their own product range – which like other examples are independently verified, but here also connected with other forms of best-of-best with the verified trust born out of the FIPS-140/2 Encryption Standard – see: https://docs.microsoft.com/en-us/compliance/regulatory/offering-fips-140-2, which provides a double whammy of verifiable trust. Thus, Certified Product are a definite feature in the set of Secure Building Blocks. As an example, at Fig 5 depicting an iStorage M2 diskAshur FIPS-140/2, Common Criteria EAL5+ Certified Encryption Key.

Fig 5 – Certified Product example (Verified Trust)

• Network Infrastructure: When we arrive at the level of wired, and promiscuous (AKA WiFi) environments there is need to exercise the practice of robust configuration of assets, assuring there are fully documented Standards in place for each element supporting the operational infrastructure – here we may also join with other verified blocks around area of standards, say ISO/IEC 27035 (Incident Response) or ISO/IEC 27031 (Disaster Recovery). Agreed, there will be some push back here which my assert that this is again, in place already. However, I can again call on my own first-hand operational experiences which have, on multiples of occasions proven that his is not always the case – ranging from, at the worst end, and ill-configured SAMBA sitting at the absolute core of a well-known banks infrastructure, which had been missed on each occasion the bank called in its annual pen testing team, thus exposing the enterprise, and in some places external connection to their India based Third Party supplier – possibly why this particular bank suffered multiples of multi-million ghost transactions! In another example from a cast of many, one UK Government Agency invested a significant amount or time, resource, and funds to virtualize their entire operational area in order to secure their classified, sensitive data assets within a physically secured computer room. However, they overlooked the fact that sitting outside of the presumed, secure facility, they were hosting several MFD’s (Multi-Functional-Devices) – AKA big powerful computers that just happen to provide a print facility. In this case, notwithstanding there was a warm feeling that all data was secure, the MFD’s stood as silent witnesses to the fact that they had been overlook, had no security configuration applied, and that they were hosting the crown-jewelled sensitive classified data objects, which were both logically and physically available to unauthorised users with data at-rest on the internal hard drives, and associated on-board print-server. My last example is the bank who were compromised by several .cn (Chinese) remote access servers which were connected to the very core of this, high-profile, governing London based, long established bank. When notified of the discovery though the use of OSINT methodologies, the bank took immediate action to remove, what had been a long-established breach. However, as they only dealt with the reactive stance, and failed to deploy proactive capabilities to watch for other such illicit incursions, the .cn connectivity was re-established within three months, and seemed to go on extant and unchecked. Given such high-profile fallings, it may therefore be robustly concluded that there are dangerous gaps in this area, thus the element of a employing proactive Building Blocks to ensure that all operational objects are secured under an agreed configuration standard is vital – it is also essential that this Building Block is conjoined to a proactive element which continually looks out for any areas of potential exposure – before they are exploited.
• Cloud: Outsourcing Mark 2 is what I consider Cloud to be in 2021. Granted with more flexibility and switching capabilities – but at the end of the day, it is your data in someone else’s Data Centre. Again not to ignore the overall objective of the Verified Trust approach to deliver joined-up Building Blocks, we need to keep in mind all areas of risk which may be present, and thus, also need to consider the implications in both positive, and negatives sense of the Physicality and Operability elements – avoiding over focus on the logical aspect of the risks, and stepping up to the plate to look how some operational expectations may be over complex, and lead to a Cloud issue presenting an end-user physicality impact, such as say, being locked out of a car, due to a Cloud based server issue! Here, we again also need to plug into the other relational Building Blocks, such as those residing in the Physically and Standards Domain – e.g. the ISO/IEC 27017 providing direction on Cloud Management, the ISO/IEC 27036 covering Supplier Relationship Management, and other directives which cover the physical implementations of a deployment remembering that, according to a report published by the Ponemon Institute it is estimated that 51% of data breaches were attributable to Third Parties, with 44% suffering on onward breach within a 12 month window, and the finding that a whopping 74% were down to providing such trusted agents with too much access and privileges! If you need proof on this area of potential insecurity, you can look as far as the SolarWinds debacle, and not forgetting Kaseya. In the Cloud user SME sector, there can also be an expectation that, if they have provisioned a Cloud provision though say AWS, or Azure then the security posture may be taken for granted – no at all, as whilst you can outsource a service, you can never outsource your security responsibilities – and that also goes for assuring your procured domains are safe, and correctly and securely configured. Again, there will be push back with a, yes, yes, we do that already. But if that is the case, how come one Local Authority in Scotland were hosted on an AWS Cloud without their knowledge (they only discovered this post a cross-domain exploit). Or maybe consider the Australian Bank Group who found their PCI-DSS data was being stored on an external staging server at an ISP, mixed in with multiples of other datasets without their knowledge or consent. Bottom line is, a good, well managed Cloud selection can bring many benefits to the business, a bad one can be a potential nightmare. Thus, here it is necessary to ensure that the Building Block to support Cloud is both robust, and fully relational to the usual CIA-A model (Confidentiality, Integrity, Availability (remembering Tesla), and Accountability).
• OSINT: Possibly one of the most powerful tools in both the Proactive, and Reactive sense is the capabilities of OSINT (Open-Source Intelligence), and yet, as of 2021, there would seem to be very little take up of this powerful set of methodologies which are on the greyer side of the Cyber-Security Model. At the higher level, consider OSINT as the eighth layer on the usual OSI 7-layer stack – see Fig 6 below. Think of OSINT as an overarching methodology which can potentially see into both the future, and the past – it is a tool which can reveal those unknown unknowns which may be exploited to compromise your supposed robust cyber security posture. – it is a tool which can embellish each of its sub sisters within the OSI 7 Layers of expectant security. For example, it may be utilised to review your entire domain, or domains to discover any inbuilt insecurity, of points which could manifest in Data Leakage or unauthorised incursion. Or maybe to discover a poorly configured X509 Certificate which could lead on to exposing your, secure deployment. However, as powerful as this proven methodology is, it is yet to catch the eye, or interest of many commercials and government agencies who missing a trick. Given the on-going stride of security exposures and high-profile compromises, the OSINT Building Block which can underpin a robust security posture is one that needs to be created, understood, and leveraged with some urgency.

Fig 6 – OSINT and Layer 8

• IR/DF: Standing for Incident Response, Digital Forensics. Here we consider the elements which apply when all else would seem to have failed. On the basis that there are three types of organisations connected to the Internet in 2021, which are as introduced above a. Those who have been hacked, b. those who will be hacked, and c. those who have been hacked, but who are unaware. In this Building Block to furnish the Incident Response, and the conjoined Digital Forensics Capabilities, there are multiple cross-over and connections with many other of our established Building Blocks – from Skills, to Policies, the underpin of Laws and Legislations, the required Toolkits and associated Training, Documentation (Runbooks) and more importantly the awareness that this is a capability which must reside outside the controlling hand of IT, with complete autonomy. We may also consider the First Responder Capabilities, and the connection with the SOC (Security Operational Centre) sitting within an established and agreed Operational Framework – see Fig 7 below. One fact is for sure, call it a Building Block, Trusted Process or Dooley-squat – if you don’t have established, mature capabilities of this nature when bad things happen, there are two possible outcomes, which are 1. You get lucky, or 2. You become a breeding ground for a lot of headless chickens in that time of stress. PPP (Prior Planning Prevents P…. Poor Performance).

Fig 7 – Incident Response Framework

Again, looking at the aspirations and conversations around the complex, and at times misunderstood area of Zero-Trust we should also consider as a comparator the health and progress of the current landscape of cyber defaces which have been followed and been deployed over previous decades. For example, whilst we are sitting in the middle of a vicious and successful cyber-storm, encountering security breaches and compromises on an unprecedented scale, on an almost daily basis, it would seem, notwithstanding this fact, there are still serious gaps in the defensive postures and capabilities one would expect to find in place. For example, a recent survey conducted by the much respected SANS published October 2021 reported some disturbing facts on the subject of Security Operations Centre take-up – See Fig 8 below.

Fig 8 – SANS Discoveries on SOC Progress

As we may conclude from these reported SANS discoveries, in which we observe the potential challenges and shortfalls which range across our landscape of Security Building Blocks – inferring with strong relational context, there is much work to be done putting the basics back in place, before we rush to deploy yet another complex technology such as Zero-Trust without first setting the overall landscape into good order. Papering over cracks never has a long-standing effect!

Add the above the findings of an article published by eMazzanti Technologies (Jennifer Mazzanti) on 25/11/21 titled ‘7 Lessons to Apply from 2021 Cyber Attacks’ who site Experian as one example who hosted a breach concerning 24 million accounts, and 800,000 companies. Here, eMazzanti draw conclusions such as there are still gaps in understanding the levels of risk, and even as today Patch in Fixing are still leaving gaps though which successful attacks are achieved, and you may start to observe yet again, that there is a need to apply the nuts-and-bolts of the good old back-to-basics, before we rush out to overcomplicate the insecure – see URL below:

https://www.prnewswire.com/news-releases/7-lessons-to-apply-from-2021-cyber-attacks-301431287.html

Note 3 – Historic Cross-Block-Issues: Looking back on some known areas of exposure as presented above, I would ask that the reader just ponders for a moment on the overall implications. Take the bank who, in the last decade were hosting an insecure and vulnerable SAMBA service at the heart of their operations, which was continually overlooked by the annual penetration test, and their in-house security team.When this security exposure was brought to their attention, one senior security professional, they commented that ‘the only SAMBA I know of is a dance’ – very worrying indeed. Even more so as the related security concerns around SAMBA and NFS have been fully documented since 1991 (and before) in the following publications:

PRACTICAL UNIX & INTERNET SECURITY – ISBN 1-56592-148-8 Authors Simson Garfunkel and Gene Spafford

LINUX SYSTEM SECURITY – ISBN 0-13-015807-0 Authors Scott Mann and Ellen L. Mitchell  

I hope you would concur that the real operational concern here is, there are security professionals overseeing the aspect of gross insecurity at the potential expense of their employers, and more the case, given this was (is) a bank their clients. Thus, here we should be considering a shortfall of secure expectations the areas of skills, security configuration, network, and standards. As I said, these are real-world examples, so perhaps we may start to understand and appreciate just how modern-day security breaches are occurring.

Conclusion

Whilst I have no wish to introduce yet another buzzword and am thus caught between the devil and the deep cyber-sea, so for sake of correctness, please feel free to call it what you will. The point being, we are introducing what has been known and practiced in parts for decades, but along that journey we may have wondered of the righteous path as we stumbled into the complexities of the new age, always on, fast moving, ever changing digital world. The overall objective of the Verified Trust, Building Block approach is build a Wall of Conjoined Security, to look at what we have been doing right for decades, to reinstate what we may have forgotten, and to leverage the best-of-best tools, methodologies, standards, and those independent product/application reviews and certifications that allow us to sleep much better at night, in the awareness that what we are trusting has been designed to a high security standard from which we may derive verified assurance. With such an approach delivered cross-enterprise in a complimentary, interwoven form, driven out of related Building Blocks with the associated overarching multi-relationships of technical and governance frameworks, we may start to create a security structure which will be robust by inference. It may be that, looking at what is being suggested here, there will of course be those who feel they are doing some of this already. However, with the case studies, and known knowns of all too often security breaches, one may be forgiven for concluding that, what is in place today, is not necessarily representing joined up thinking. Granted, there is nothing new in the isolated areas of technology, and other forms of process, procedures and instrument of underpin – but it is the overall attempt to pull out the mindset that if we start at the bottom, and work up through the best-of-the-best disciplines, technologies which have been subject to Government issued and recognised secure status, we may just start to see this pay off in end game of delivering a more robust, functional, joined-up security posture. Not necessarily looking at the world of Zero-Trust which we have lived in for decades – but to enable a back-to-basics approach that looks at the complexities of the required cyber security model, in a world which is suffering from escalating technical complexity of successful security breaches. A 100% secure posture is simply not a possibility – but if we go back-to-basics and lift the lid on what we are doing (wrong) today, we may then, possibly enjoy the benefits of achieving a shrinkage of the presented surface of attack we are offering up for potential compromise.

To end this paper, I can hear what you are saying – all of this is just common sense – that being the case, why is common sense, at times appear to be so very uncommon.