|
Secure Space
Making IT infrastructure safe and secure
 Is
your IT infrastructure secure? Would you bet your company’s future
on it? Unfortunately, says AJAY GIDH, most enterprises fail to recognise
their IT vulnerabilities until after the damage is done
Since 9/11, security and risk management
have become a priority for discussion in all areas of business life.
Technology security has also been a high-ranking topic for a number
of years now—with the proliferation of hackers, viruses and Web
page defacements. In this day and age systems security should be
on every organisation’s agenda. The business problem of security
is that security solutions require continuous, onerous cycles of
development and maintenance. Hackers, crackers, bugs, insecure operating
systems and business evolution will always be a fact of life and,
as a result, new security threats and holes will constantly appear.
All of today’s security solutions will need to be continually updated
to remain effective: they will need patches, upgrades, support and
perhaps replacement to provide the same value tomorrow.
In such a scenario, IT security
solutions usually have a large gap between the expected benefit
and the actual benefit. To make matters more complicated, an enterprise
usually does not have the highly specialised, expensive resources
in-house, that would be needed in order to define, develop and validate
an IT security solution to meet those requirements.
Thus, enterprises usually rely
on a security service provider that can help identify vulnerabilities
and risks in target systems and environments, develop an enforceable
security policy with clear and concise standards, provide proof-of-concept
testing to validate the recommended security architecture, document
and deploy the IT security solution, train personnel and support
the solution.
Effective IT security methodology
An effective IT security methodology
must deal with an extensive list of security properties. It is the
adequate combination and interoperation of security properties that
provide the usually required resiliency to a secure IT system, which
does not fail when subjected to an attack. There must be multiple
channels of communication and correction, even if the channels are
not 100 percent independent.
The most important security
property is trust. Risk, for example, can only be defined after
one defines what is at risk, and what is at risk must be that which
is trusted to some extent, otherwise there would be no risk. In
other words, risk has to do with the loss and probability of loss,
but only the loss of what is trusted would affect the system.
Considerations in selecting security
service providers
A security service provider,
in addition to any particular vendor’s solutions, should investigate
a broad range of solutions and technologies, using products and
systems to the greatest extent possible, modifying existing applications
where appropriate and developing new components and interface capabilities
where required, in order to provide full functionality with the
least dollar gap. In other words, a security service provider must
not consider an IT security solution as just a firewall or even
a collection of products to be installed. Oftentimes interface code
needs to be developed by the security service provider or by a third
party in order to reduce modifications of products (to prevent losing
track of version changes) and to provide collective functionality.
The solution’s functional requirements
may also motivate engineering modifications to be introduced by
a vendor into their product as an alternative, for example, to the
increased complexity of using more modules with higher cost and
reduced end-to-end security. Code development versus adding new
products (the creator verses integrator views) versus requesting
modifications is a decision process that must answer a number of
questions, including:
- Which technologies and products are
most appropriate?
- How can product mismatches be rectified
in our system?
- How can we engineer system attributes
such as reliability, security and performance in spite of decreasing
control over individual system components that come from COTS
products and their changing versions?
- How do we integrate new products
with the custom code we already have?
- How do we gain advantage while delivering
a solution that can evolve over a long lifetime?
These points are central for
reducing the dollar gap and creating conditions for a favourable
RoI.
The importance of a solution development
methodology
To provide full solution functionality
at the lowest cost, the security service provider needs to apply
a solution development methodology that simultaneously considers
the solution’s requirements, cost, schedule, operating and support
environments, capabilities of products in the marketplace and viable
architectures and designs. All these items are dynamic and interact
with one another.
The first challenge of the
solution development methodology is to adequately define the solution’s
requirements. Second, the solution development methodology should
leverage the initial development effort into a finished product
with the least rework. The third challenge of the methodology is
the high level of assurances required to ‘do it right the first
time.’ Here, experience and proven performance must outweigh potential
gains.
The solution development methodology
should preserve the proven performance of any selected product.
Additional challenges exist in any solution’s development, the foremost
being the risks associated with incorrect and optimistic status
reporting. One of the most common sources of problems in software
development is the fact that software project status reports are
not accurate even though they may seem to be believable. Far too
often, monthly status reports optimistically state that all is on
schedule and under control, until shortly before the planned delivery,
when it is suddenly revealed that everything was not under control
and another six months may be needed. But usually, a business solution’s
deployment has a deadline that is quite immoveable.
The solution’s project status
reporting needs to address this concern head-on, including progress
tracking and realistic metrics. Monthly status reports with earned
value measures should be used as a tool to give enterprise and project
managers a clear and precise indication of everything that is right
and everything that is wrong with the condition of the project as
of the current moment.
To reduce rework and missed
expectations in solution development, the security service provider
should require testing or credible test references for all components,
including hardware, software design tools, compilation tools, debugger
tools and any other tools that may be considered for use in the
solution. Additionally, the solution development methodology should
include security professionals in that solution space, who should
act as verifiers during the entire design phase and not just during
validation and verification.
The various components of the
solution need to be integrated. The solution development methodology
should include integration testing to verify that system functionality
conforms to requirements. Integration testing should be done in
two phases— validation and verification. Validation involves consultations
with local users, corporate offices and legal bodies in order to
confirm the operational assumptions of the solution. Verification
involves actual system testing in order to confirm the validated
operational assumptions are met in conditions as close as possible
to the expected operating conditions.
The enterprise should observe
both phases. When everyone is satisfied that the system is ready,
the configuration should be frozen and the system turned over to
the enterprise for certification testing before it is actually used.
Finally, avoiding those issues and conditions that tend to lead
to rework should be a main focus of the solution development methodology.
Risk management measures need to be used, including schedule time
for minor system rework to address any anomalies identified in testing.
The author is managing partner,
retail solutions division—professional services for South East Asia
at NCR. He can be contacted at ajay.gidh@ncr.com
- Implementing an ‘open unless closed’ approach
to security configuration. This means an organisation lets
everybody have access to everything unless they absolutely
don’t require the functionality. The problem is that
unless the person implementing security understands every
function, access rule, workflow, and associated program
(and that’s a heck of a lot to remember)—your
security strategy is at risk of being flawed.
- No security strategy has been determined and the configuration
of security becomes unmanageable. This occurs when people
give up using the current process, fudge a user profile
and then get creative with system management. It’s
important to remember there is far more functionality than
any user needs in these complex solutions.
- The security is so restricted that staff cannot carry
out their required functions. If this problem manifests
itself within an organisation, it’s clear security
testing was inadequate—otherwise it would have been
addressed.
- A breach of duty segregation and access to conflicting
functions. The following questions should be asked: Who
has access to both bank maintenance and approval? Can one
person raise and approve? Management needs to make the decision
on how to mitigate such risks.
- No security testing strategy is defined within the implementation
or upgrade plan. If you don’t test security how do
you know if your staff can perform required functions? What
if security is so loose that users have access to sensitive
functions or inadvertently change the chart of accounts
or codes? These things do happen.
- No monitoring or escalation procedures are in place for
attempted attacks or permission refusals. There is an element
of luck with hacking. Organisations should put procedures
in place to identify attacks or attempted breaches, so they
can monitor and put effective solutions in place.
|
- Access control: Gaining access to objects, based
on the trusted identity of users; limiting access to system
resources only to authorised users, processes or systems.
- Audit: Maintenance of a historical log of all
transactions that can be reviewed to maintain accountability
for all security-relevant events.
- Authentication: Corroboration of a credential
or claim; the ability to establish and verify the validity
of a user, user device or other entity, or the integrity
of the information stored or transmitted.
- Authorisation: Conveyance of rights, power or
privilege to see, do or be something.
- Confidentiality: Ensuring that data is not available
or disclosed to unauthorised individuals, entities or processes.
- Integrity: Ensuring that data is not altered or
destroyed in an unauthorised manner.
- Non-repudiation: The ability to prove the origin
and delivery of transactions; the ability to prevent the
effective denial of an act.
- Process validation: The ability to periodically
validate the correct operation of the solution’s processes
and security functions.
- Security management: A defined process to perform
system security functions such as audit, management and
configuration management.
- Trust: Qualified reliance on information; trust
is that which is essential to a communication channel but
cannot be transferred through that channel.
|
|
