Some food for thought & perspective on application security and the need for a rigorous risk modeling approach.
Perimeter security is inadequate
1. The majority of IT security spending is focused on perimeter security. These measures are reactive in nature. Given the cross-perimeter scope of modern applications, this approach is ineffective.
2. With the advent of Web Services and SOA, the attack surface is more exposed and is getting more complex. The more complex a system is, the easier it is to compromise. SAP, Oracle-PeopleSoft are very vulnerable. SAP Enterprise Portal presents with Browser vulnerability that we addressed in my earlier blog. While Business Managers wrestle with SAP to get reports out – Hackers have a cake walk to steal data from SAP.
This view was echoed in a SANS Institute webcast that shows perimeter defenses were not designed to counter the threat vectors that attempt to compromise software applications.
While the business of application delivery focuses on the assurance of functional use cases, the security of these applications must address the related abuse cases.
This approach is possible if a focused, proactive testing framework is applied throughout the SDLC or Implementation stage of an ERP, not just at the release – go live stage.
Business Software, like any other product, must go through a quality assurance process that looks for vulnerabilities.
Business Software design & Implementation must address risk
Software implementation must have security built into it rather than being addressed as an after-thought….
Software developers are typically concerned with delivering their product on time and with the desired set of features. They typically don’t think of security measures. For example – SAP Passwords can be easily compromised because there is no encryption. It is a very basic need but SAP has not bothered to fix this till date.
A lot of custom ABAP code is written by college kids who have no clue of SAP security.
You can’t blindly identify problems inside of code without taking the risk element into account. But no one checks or institute a code review- the ABAP code for Secure parameters. I have seen 2000 -3000 ABAPs in a mid size company. They have a Frankenstein & not SAP ERP.
It is easy to think of risk conceptually – it is the impact of an exercised vulnerability on a business.
The difficulty lies in perceiving risk in a context shared by management, communicating it to other stakeholders, and using that understanding productively.
Risk must be modeled in a business-centric way
There are many threat modeling approaches available to aid businesses and individuals in assessing applications.
The Open Web Application Security Project (OWASP) highlights methods to characterize threats by their effect on an environment and by the types of exploits that could exercise them. CoBIT has a sophisticated risk management approach for ERP and other applications.
While this information is helpful, risk assessment must focus on the implications of vulnerabilities on business continuity.
How you assign risk has more to do with how you run your business than any technology issues you may find.”
Engineering
Engineers have a granular understanding of code that is shared by few other stakeholders in an organization. This insight makes them critical in remediating code vulnerabilities.
This insight can also be a liability, however. Given their intense focus, engineers may not consider the business issues that drive the use of their applications.
This is where business analysts and management step in to communicate this information
Line-of-business management
LOB stakeholders are able to communicate the business value of the applications in use and the processes their support.
Without their help, the whole risk assessment initiative will fail. Their role is especially relevant in organizations with multiple lines of business.
While these departments work for a common company, their organizational goals and politics will vary.
I have seen the same application have a different risk profile accross different internal organizations due to usage patterns.
These differences require organizing leadership in order to create a cohesive understanding of risk.
CISO/CSO
The engineering and middle management perspectives must be aligned to address the strategy of the organization.
This responsibility must be championed by a C-level executive that can balance the need for security against the competitive drivers of the company.
CISO – a IS leader must be able to balance the needs of individual business units against the strategic demands of the company.
