Cost and time constraints can impact the attitude and focus of project teams towards security and controls considerations in major enterprise software projects. To avoid compliance issues in the long term, it is important to find potential remedies to this issue.
In the current climate there is little escaping the focus on cost reductions being directed from the top of big businesses across the majority of industries. The issue is therefore high on the agenda for most CIOs, as a result of which it is largely driving the selection of suppliers and methodologies for the delivery of projects.
This post is based on my experience of SAP projects, but the arguments stand for all major enterprise software projects.
Tighter time constraints for delivery and a focus on adhering to budgets and deadlines, can result in decisions relating to the Security and Controls (S&C) in SAP being compromised.
S&C is a vital mechanism in protecting businesses from risks related to the data they hold in SAP and compliance. It determines the level of access to information and system capabilities that each SAP user has in order that they can perform their role, but are not authorised to access data or transactions that are deemed sensitive.
When dealing with implementation or modification of functionality in SAP, regardless of the module, an impact on the existing security build should be expected and considered in the project plan. Based on the current trend to reduce cost and time scales for such projects, the likelihood is that security considerations will be compromised to a degree in order to ease the strain on the project team to meet ever-decreasing deadlines. These might include:
- S&C requirements only being considered after functional components, the actual enhancements to business capabilities, have been configured
- Existing S&C processes, such as approvals for development access or Segregation of Duties (SoD) controls, not being adhered to throughout the project lifecycle across the SAP landscape, resulting in the system being exposed to risks that are otherwise controlled in business as usual activities
- Testing not taking into account the new and existing security concept and SoD controls, causing it to ultimately be invalid
Severity of the impact of these will depend on a number of factors related to the specific organisation; the maturity of its current SAP build and processes governing changes to it, the support organisation and business ownership of SAP Security, and the security awareness and S&C experience of individuals making up the project team.
The value of the risks, that are mitigated by considering and adhering to S&C controls, is very often not quantified or fully understood by the business. Greater consideration should be placed on the purpose of controls and their protection of the organisation, from risks such as fraudulent behaviour, leaks of competitive information, or non-compliance resulting in fines. Better understanding of the link between S&C concepts and risks would be likely to force improvement to governance processes around project activities, in order to validate that project teams deliver an effective S&C solution without breaking controls in the process.
Designing in security from the start
The focus during the design phase of a project will naturally be placed on the functional components to be delivered, as these are the key business drivers and the main interest of the project sponsors. Support and administration considerations - ‘non-functional requirements’ (NFR) - are commonly tackled later in the design process, and are often expected to fit around the way the functionality has already been designed and agreed to work for end users.
Security is a component that typically is considered along with NFR’s at this later stage, but ideally should be separated and included in the functional requirements, or independently as explicit security requirements. However, because security is often seen by the business as simply an enabler of the functionality, there may be a reluctance to prioritise it in a project plan and budget if the value of the controls it enforces is not fully understood by project stake-holders.
A functional blueprint that does not consider security gives rise to the potential for decisions to be made without consideration of existing S&C standards and predefined SoD controls across the business. The impact of such decisions, exacerbated by tight deadlines and budget constraints, can result in projects delivering security components that break from documented standards and compromise audited controls.
Add to this the potential for security deliverables to be over simplified because modelling complex but more effective solutions is too time-consuming, and the result is likely to be detrimental in the long term to existing controls put in place to protect the integrity of the system and data. The overall result is heightened exposure of the organisation to risks that are likely to amount to greater cost in the long term.
Organisations should ensure adherence to security controls across their SAP landscape via a controls framework, governed by internal and external audits on a periodic basis. Although live production systems are the key focus for these controls, it is necessary to gain assurance that security is administered in a controlled manner throughout the wider SAP landscape including development and test environments. If approval processes are not enforced by a party independent from the project team, the temptation will be to bypass them where possible in order to assign wide access to carry out development or testing responsibilities and avoid authorisation issues.
By ignoring approval processes for authorisations or SoD, time is saved by negating the need to justify access requirements to approvers. Breaking of controls in this manner exposes risks such as misuse of sensitive permissions impacting business as usual SAP, external parties gaining rights to view sensitive company data, and modifications being made to system configuration without the necessary sign offs on the design being sought. All of these risks have a level of financial impact on the organisation, be this in the long or short term.
Maintaining controls during system testing
Underestimating security as part of testing is common, regardless of time or cost constraints. In the situation where the timescale is limited, security will often be disregarded to a degree to accommodate the need to meet a deadline for completion of testing. Project teams see the ability to test without full security controls to be an advantage because it enables them to reduce the number of people required to execute tests, and avoid timely security issues in the short term. However, this is likely to result in post go-live issues where-by the solution cannot be used as tested without breaking S&C controls. To counteract this, the test strategy for any SAP project must state that test users are to be setup in line with existing controls, including SoD. It is also vital that security testing is included in the integration test cycle to ensure that security development is complete prior to commencing the user acceptance test phase.
The individual responsible for signing off test completion should understand the value of ensuring S&C has been considered to an appropriate level throughout testing, to avoid the further cost of post go-live remediating. It should be stipulated that tests carried out by users with sensitive or conflicting access, or access that will not be approved for assignment in the live system, are invalid.
Stakeholder endorsement of security
The attitudes of key project stakeholders are a major factor in ensuring a project makes adequate provision for S&C requirements. They should convey the value of effective S&C decisions, and adherence to controls, to the project team to ensure S&C is prioritised appropriately. Attitudes of stakeholders will vary dramatically between organisations, and may also be influenced by pressure from management to deliver a seemingly effective solution to the business, on time.
There may be a temptation for the project manager/business sponsor to reprioritise security requirements, re-planning them for a later phase or encouraging the project team to simplify them in order to meet a deadline or budget constraint. Those individuals who sign off the design should ensure that S&C is considered, however they may have limited technical knowledge. The effectiveness of security deliverables is more difficult to measure by testing, compared to business functional requirements. This makes it challenging for these individuals to maintain control over what is finally delivered unless they are working alongside someone with a greater focus on technical elements of S&C.
The risk of project outsourcing
Currently tied in with the need to reduce the overall cost of SAP projects, there is a trend for organisations to outsource delivery rather than resourcing independently and managing internally, with the main driver being guaranteed delivery to cost and date. Unless very tightly controlled, external running and resourcing of a project often distances the business and the SAP support organisation from the implementation, which in turn reduces their ability to influence decisions made and adherence to control processes.
An outsourced partner should have the technical capabilities to deliver requirements outlined by the business, and the infrastructure and resource available to manage execution of delivery to agreed cost and time. However, because simplifying security deliverables and bypassing controls allows time to be saved with little direct business impact, the potential for security to be implemented against the organisation’s standards, and for controls to be ignored throughout the lifecycle of the project, is heightened when an outsourced partner is given responsibility for S&C.
An outsourced resource will often have little knowledge of the organisation’s control framework and therefore less incentive to follow process and establish the necessary evidence for future audits. There is a considerable risk when devolving responsibility for S&C to an outsourced resource working within a wider project team that, because they are constrained to deliver to set timescales, controls will be broken and future-proofing of the solution not considered.
As organisations across all industries increasingly rely on third party vendors because they continue to offer delivery of requirements at the most competitive price, businesses will need to improve vendor management and better scrutinise the quality of delivery in order to future-proof their SAP solution. S&C standards and processes should be communicated to vendors from initial engagement, and the organisation must be clear in outlining requirements and expectations as a benchmark. The likelihood is that scrutiny of the quality of solutions delivered by vendors will initially focus on functional deliverables and not security. The quality of a security solution is unlikely to be reviewed unless post go-live issues related to it become common place, negatively impacting business critical processes, or concerns are raised by auditors forcing remediation of issues.
The need for an S&C ‘champion’
Organisations who endeavour to take S&C seriously must find a resolution to the tendency to cut corners in order to reduce the need for rework in the long term, while still meeting cost constraints. The key to avoiding the issues covered in this article is to have at least one individual on a project team whose sole focus is S&C, and who is accountable for delivery of an effective solution that fits with predefined standards. That person must have the necessary level of technical understanding of SAP Security and the controls framework in order to carry out their role effectively being mindful of the value of controls to the business. They should also be responsible for championing S&C processes and the purpose of them, with support from project management.
Whether this role is sourced internally or externally, it is most effective for the individual to work independently of the project team in order to negate the conflict of interest between delivering a quality solution and delivering to timescales. The immediate cost of this resource should be justified by comparison to the potential cost of lack of controls in the long term.
An alternative solution to segregating delivery of S&C requirements to a separate individual would be to employ a quality assurance (QA) resource to focus on S&C, to work alongside the project team. The QA’s purpose would be to verify the feasibility of the proposed S&C solution and to ensure that audit controls are being met.
The importance of the long-term view
Security professionals are all likely to agree that the task of getting a good level of ownership for security within an organisation will always be an uphill battle, mainly because it is possible to have functioning business solutions in SAP with a poor S&C model to back them up. However, as organisations devolve more responsibility outside their absolute control this focus must change to ensure that processes are in place to protect their systems, and data and that their S&C model is not compromised.
The business and project governance teams must understand the long term impact of poor S&C delivery and the consequences of control failures. Ultimately, issues as a result of a poor project implementation will need to be remedied because they are fully auditable, and the business is accountable for adhering to its own, or government imposed controls, such as Sarbanes Oxley.
The current economic climate is certainly challenging for almost all organisations. However, reducing the focus on S&C, whilst possibly effective to reduce costs in the short term, is ultimately more costly when increased risks are factored in. A more effective approach is to ensure that investment in security is regarded as a key element of an organisation’s overall success - and is therefore included as an integral element of its long-term business strategy.