Essentially, the trick is to identify the security requirements of
any new software or…
This week’s blog takes a look at onboarding information systems. When onboarding is
mentioned in terms of information security, typically, most will conclude it’s referring to
people, and particularly the starters and leavers process.
However, it is also important to consider the onboarding of new software and systems
into our operational environment.
In this context, we need to understand that while the IT department is the custodian of an information system, it is
the responsibility of the asset owners(s) to ensure that their asset, i.e. the new software or system being introduced
includes the necessary safeguards to protect the information that it might store, communicate or process.
Generally, we find the views of system owners and information asset owners differ in terms of what protection should
be provided. Their primary concern is often biased by their respective roles in the organisation.
However, the common denominator for both roles is the confidentiality, integrity and availability of the assets under
their control, although they may differ about how important each aspect is. The truth is, the importance of all of these
areas should be driven by the information itself.
Therefore, for most software and systems, it is the information asset owner that should determine how much protection
should be provided, not the technical person responsible for the system/software.
Therefore, the system or software owner should consider this in the design phase and seek early input and engagement
from the information asset owner. It is vitally important that the business determines what the risks
are to any information that may be stored, processed or communicated by the new system or software i.e. provided
by the information asset owner.
Risks should be documented and communicated to all those concerned. The result should be that the requirement for
suitable controls is identified early in the development lifecycle of any new software or system, allowing the controls to
be built in from the ground up, rather than ‘bolted on’ afterwards.
It is imperative that the documentation regarding business and technical requirements are compared to ensure that they
complement each other and are available to all relevant parties. Therefore, during the planning phase, any development
project should include business and technical requirements through bilateral communication between the business and
The outcome of this phase should be a project brief or a business case outlining the technical requirements, deliverables,
security controls required, type of data processed, roles and responsibilities and timelines. Where required, the organisation
may choose to revisit the cost-benefit ratio to ensure that the cost of implementation is lower than the risk of not implementing
an information system.
The design stage of the project should focus on technical architecture and business workflows. It is advised to commence
with business, workflows to allow the technical team to review their initial plan and ensure that the technical solution is fit
for purpose, particularly with regard to the security requirements of the system. During the design of business workflows,
the business may work on defining deliverables or at least its expectations of what outcomes are expected, the format, the
criticality of information and requirements for any additional security controls.
Any deviation from the agreed scope of the new software or system could significantly increase the risk that the solution may
not be fit for purpose. To ensure risk is controlled, a project risk register should be considered. Such a register allows for a
transparent overview of any issues that could have an adverse impact on project deployment, including where the requirements
for security have not been adequately met.
In some instances, internal verification and validation may not provide adequate assurance that the security requirements of
the new system are sufficient. Where the system is hosting, processing or transmitting sensitive information, independent
verification should be considered in the form of a compliance audit or thorough penetration testing.
Essentially, the trick is to identify the security requirements of any new software or system as early as possible and to ensure
that these requirements are delivered, whether the software or system is a commercial off-the-shelf product or as a result of
PCI DSS – The devil is in the…….Diagrams Within this blog, we are not going to delve into the murky depths of why a network component may be in or out-of-scope (thank goodness I hear you say)…we’re talking about DIAGRAMS! Read more https://t.co/mesw2hhugc #pcidss #infosec pic.twitter.com/s1BN2oEXVU
— URM Consultancy Ltd (@URMRisk) 26 July 2019