A certified Information Security professional, with demonstrated experience spanned more than 10 years in financial, banking, consulting, and payment card industries in managing Information Security System Management ISMS.
A post graduate degree holder in Information Security Management (M.Sc); Certified Information Security Manager (CISM), Payment Card Industry Qualified Security Assessor (PCI QSA), SABSA Chartered Security Architect (SCF), ISO 27001 Lead Auditor, CREST Registered Technical Security Architect (TSA), CREST Registered Penetration Tester (CRT), and a member of ISACA.
Demonstrated to be reliable, trustworthy, and meticulous person; working in a controls-focused environment, multinational, and multicultural organisation over the years and gained a good understanding of what is required of the Information Security professional. .
ISMS based on ISO/IEC 27001/2
Payment Card Industry (PCI) DSS - QSA led services - PCI Scoping, Gap Analysis and Formal Assessment (RoC)
IT Governance, Risk and Compliance (GRC) Management
Enterprise Security Architecture
Technical Security Architecture
Incident Response (IR) is the decision away from having your business go down under or resurface after a few hours.
Most organisations have IR shelved somewhere collecting dust. The IR is good to the extent to be shown to auditors for compliance tick box, however not to the extend to save the business when it comes the time to do so.
We have heard a lot of stories on the internet and front-pages of data breaches, the most prevalent theme is the difference between detection time and discovery time, that is the time when the incident actually happen(when the hacker breached your systems and resides in) and the time when the organisation when actually discovery the breach happen. Organisation takes long to detect the breaches and when they do, they can’t get their IR plan running as expected. This boils down due to the fact that the IR plan have not been tested on frequent basis (not annually :), this need to be more frequent than that).
IR coordination activities is not only to be managed by the cybersecurity department, the activities need to be organisation wide, this should include senior management (CxO officers), public relation, business units, IT and cybersecurity departments.
My 2cents, organisation need to to the below when comes to IR
– Draft IR plan which should include all the critical business unit
– The IR plan should have communication plan and assign the ultimate decision maker e.g. CEO, CIO or C-Level executive
– Test different scenarios e.g. state-sponsored attacks, physical attacks, insider attacks etc.
– Test more than twice a year (not table top exercise, actual war games)
– Improve your plan once tested, from the lesson learned.
I am PCI QSA,
part of PCI assessment require assessment of physical security controls for
systems, this include but not limited to visit facilities e.g. data centres,
computer rooms where CDE is hosted. I have had a good share of visiting these
data centres and computer rooms. I have seen the best physical security
controls from acoustic wire, bomb shelters, shutter proof windows, mantrap
insider the mantraps, to the computer rooms locked with a key which is not
under any dual control. While most of the data centre are secure by design, the
service offerings from these data centre are also standard, including offering
dedicated suites, shared halls, shared cabinet (yes, not open your eyes wide
open) and some other companies will basically say or my system and data are in
the cloud (where? AWS, yes where? I don’t know, let’s ask our account manager).
organisation e.g. merchants and service providers who have system hosted by
third party co-location providers, may or may not understand the offering in
detail or the security department may not be involved in the decision making or
the client may have no idea from physical security point of view how the data
centre security looks like, it worthy visiting it.
This is where the all the suite
is dedicated to an organisation.
Security controls like CCTV and
access controls are pretty tight.
This is where a shared space, a
bunch of racks from different customer are on shared space.
What to look out for, how the
cabinets are secured, some are secured with padlock with keys, other with
padlock with combination, other both, and I have even since fingerprints.
Sometimes CCTV are not
installed on the aisle, for the fear of seeing client system? How? I don’t know
Organisation should understand
the co-location services offered.
Should visit the data centre if
Security dept. should be
involved in making decision in selecting security controls.
It is best to have controls
such as frequently / quarterly auditing including checking the inventory, and
have automated security controls to check for system tampering, and whether any
physical devices have been plugged to the data centre.
The UK National Cyber Security Centre (NCSC) have published the 10 steps to Cyber Security (originally published by CESG) in 2012. The 10 steps are basic security controls that that organisations can use to build a security program as minimum baseline.
The ten steps are build arounf the risk management regime and as follows.
User education and Awareness
Removable media controls
managing user priviledges
home and mobile working
While these may seem very basic and every organisation should already have in place, you will be suprised how many organisations they dont have these controls in place, including small and large organisations.
From experience point of view, most organisation they dont have mature security programs and they want to make a big jump, without starting with the basics! The proper way is to start small and build up the security program, and it should be top down approach, which the 10 steps to cybersecurity start with Risk Management Regime which should be driven by the senior management.
As SABSA reaches it’s 21st birthday, it’s worth taking a few moments to look back over its birth and development. The very first publication of SABSA was in October 1996 at the COMPSEC conference: John Sherwood: “SALSA: A Method of Developing the Enterprise Security Architecture and Strategy”; COMPSEC 96, London, October 1996. SALSA? That’s right – SALSA. But, more about that in a bit. So where did that spring from? Was it out of nowhere? No, not quite. The seeds were planted a year earlier. At that time, in autumn 1995, I was working as a consultant at S.W.I.F.T. headquarters in La Hulpe, Belgium. S.W.I.F.T. had recently been reorganised to create a new department called Global Information Security (GIS) to address some issues raised by the then external auditors. Although there had been an Inspection Department for many years (effectively an internal audit function), there had been no explicit and proactive security function. The new department was created to fix that omission. It will tell you a lot about the cultural status and popularity of ‘Information Security’ at the time that many people would say that ‘GIS’ was short for ‘get it stopped’. That was the reputation that ‘Information Security’ had gathered over three decades since its emergence in the late 1960s. The corporate information security team was seen (often for good reason) as the ‘business prevention department’. “No, you can’t do that, it’s not secure” was the catch phrase that had earned that reputation in many organisations. The newly appointed Director of GIS at S.W.I.F.T. (Erik Guldentops, previously the Chief Inspector) was keen to make sure that this poor reputation was dispelled, and that Information Security was seen as adding a positive contribution to the business of S.W.I.F.T. That business was, and still is, the transfer on a global scale of several trillion dollars per day between the world’s largest banks. (Yes, that eye-watering number is correct).
Erik’s mandate in his new appointment was to create a five-year information security strategy and get the S.W.I.F.T. Board to approve a significant budget to achieve this objective. The currency at the time (pre-Euro) was the Belgian Franc (BEF), which had a low exchange rate versus the dollar or the pound sterling. Thus the budget numbers tended to be large ones, quoted in millions of BEFs (MBEFs) or mega-BEFS as we affectionately referred to them. Erik needed to justify a multi-mega-BEF budget, for which he needed a plan that could be shown to the Board.
One grey, drizzly November afternoon in 1995 I was working in my office at La Hulpe and Erik came in to see me. “Hello John. What do you know about security architecture?” he said. “Well”, I said “I know there is an ISO standard 7498-2 that talks about OSI (open systems interconnection) security architecture. ISO 7498-1 is the well-known description of the 7-layer OSI network architecture model, but part 2, about OSI security architecture, is less well known. And that’s about it”. So Erik says to me: “Please dig around and see what you can find because I need to develop an information security architecture for S.W.I.F.T.”
Those of you who are relatively new to the game of research will be thinking “Why didn’t they just Google it?” The answer is: because there was no such thing as Google in those days, or HTTP, or WWW. There was a public internet-searching tool called gopher, which pre-dated HTTP and the World Wide Web as the document-structuring platform. Using gopher, I managed to find no other useful references to ‘security architecture’. You people today don’t know how lucky you all are with the tools now available.
So we had a starting point: ISO 7498-2: OSI Security Architecture. What’s amazing about that is that it was an outstandingly sound conceptual model from which to build a full-scale security architecture model and framework. It may have been the only document we could find, but it was the best possible. It forms the heart of the SABSA layered stack even today.
Of course, at this stage we were working on a security architecture model for S.W.I.F.T. It was only a year later, when I published the paper at COMPSEC in London, that this work was presented outside of S.W.I.F.T. under the name SALSA. Yes, the first publication was called SALSA, which stood for Sherwood Associates Limited Security Architecture. It was Andy Clark’s (a co-author, along with David Lynas, of Enterprise Security Architecture: A Business-Driven Approach) idea to use that name and we liked it. The original paper was published by Elsevier Science in their Computers and Security journal, as: “SALSA: A Method of Developing the Enterprise Security Architecture and Strategy”; Computers & Security, Volume 15 No. 6, 1996. Apparently that article is still available today.
Some time later I received a ‘cease and desist’ letter from an aggressive firm of New York lawyers that claimed I was abusing the trademark of their client. The client had a general business software package of the same name. I wrote back and politely pointed out that there was no conflict, but an even more aggressive letter threatening court action followed. I spoke to Andy and we decided we had two choices: spend the rest of our lives defending the action or change the name. Guess what we did. At least it showed that the published article was being read. And so, SALSA became SABSA. Right from the very first synthesis of the SABSA framework, security services have been one of the most important central concepts of the work. The reference to the relevant standard is: ISO 7498-2:1989: Information Processing Systems – Open Systems Interconnection – Basic Reference Model – Part 2: Security Architecture. ISO 7498-2 introduces the concept of security services, security mechanisms and security management. More importantly, it makes clear differentiations and relationships between these three concepts. The core conceptual relationships described in ISO 7498-2, as extracted for the original SABSA layered security architecture framework, are summarised in Figure 1.
Figure 1 – Core ISO 7498-2 Conceptual Relationships
We extended the ISO 7498-2 model by adding a business layer and a strategic layer above the services layer, added a products and technologies layer below the mechanisms, and extended the management both up and down to indicate that it is required at every layer of the model. Thus, was born the first SABSA architecture model. This was developed further in subsequent iterations, but more of that later on.
Figure 2 – Original SABSA Layered Model from 1996 Publication
The SABSA story now spans 21 years and has had many pivotal turning points along the way. What you see today is the result of much work and input from many different sources. In the next blog article, I shall track that development path that took SABSA from these early beginnings to the present day. Figure 3 shows just how far this original model had evolved, with multiple backplanes of overlaid additional models and frameworks. The layers are now considered as ‘views’ according to the roles and ‘viewpoints’ of the leading role-players at each layer.
Often technical support professional in the organisations i.e. IT, they tend to fall in love in buying new shiny toys, this can be a new firewall, IDS, or anything that is promised to thwart attacks. But the really questions to be asked is whether the new toy is there to protect business and align with the business objectives or it is just another tool, going to be bought and sitting there idle after 1 year of use?
In most situation cyber security consultants tends to recommend technological solutions to problems, that can be a new firewall, new IDs, new WAF, new OS etc the list is endless. What most people tends to ignore that we are not in the business of information security or cyber security, rather we are in the business to support the businesses, realising their objectives securely. That is where the term business information security comes into play and welcome to the world of SABSA.
While many of you, may you not even heard of SABSA, in a nutsell, it is a framework of delivering business focused information security. This framework/ methodology is ideally if you want to make sure you are in the right business of supporting the business achieving its goals/objectives securely.