M A N AG E M E N T
T E CH F O R G OVE R NAN CE
While such business rules may save some time; this is definitely the worst practice to adopt. A typical request-approval workflow works on the basis of the requestor (the maker) posting a request and some approver (checker) taking a decision to approve, reject or hold the request. This workflow is generally disrupted by adding functionalities like the ‘checker being able to modify the request’ or the ‘checker being able to delete the request’. In such a scenario no there is no validaAppSec professionals are often expected tion or approval on the action taken by the to perform miracles and mitigate flaws that checker and the very essence of the makerare often connected with the lifelines of the checker mechanism is lost. AppSec can only application. While business pressure will detect flaws (if any) in the transfer of control always compel the teams to have applicafrom the maker to the checker; But it can tions up and running; it is never an easy sitnever challenge the business rules or the uation for any CISO to let such applications excess privileges assigned to the checker. fly without the proper checks and balances. Password Management Here are a few crucial factors that every Auditing for password management is CISO needs to consider before signing-off always a tricky situation for AppSec profesapplications and eliminating the blind relisionals. While AppSec can always verify ance on AppSec assessments. Although password strength, secure password storage AppSec assessments are vital they can and transmission. AppSec not dictate terms never address the people, processes & techon the hard-coding of passwords into applinology completely: cation frameworks. The most commonly found password Lack of STP (Straight-Through-Processmanagement lacunae are Hard-coding ing) & Manual Hand-offs passwords into macros and stored proceAppSec can never be held responsible for dures and using a uniform password across processes that are offline or that are perthe application framework. Because these formed manually. While AppSec testers can passwords are hard-coded and difficult to test for data validation; they can never test change application development and infrafor business rules. It is a common practice structure teams often seeks exceptions to in several organisations, to have online ‘never change the passwords of the target workflows that detach themselves into systems or databases.’ (smaller or multiple) manual tasks. Besides this; AppSec can also not address These could include physical verification/ the problem of password sharing among the inspection, offline approvals or matching application development teams. records with another system. Whenever there is manual hand-off; the application has Excessive Super-User privilege abuse to rely on the validation of the incoming data. Singular administrative user credentials This data can never be tested AppSec being used by an entire team for local/ resources. This is simply remote administration like because Applications only conrunning backup scripts, routrol the use of resources granted tine batch jobs or updating to them, and not which resourcand patching, is one the worst es are granted to them. enemies of AppSec. While AppSec assessments Intentional disruption of revolve around the application maker-checker mechanism COMPUTERS HAVE components residing on the One of the most observed pracBASIC SOFTWARE infrastructure; having multiple tices with corporations is the SECURITY super user identities or sharing dissolution of the maker-checkcredentials of administrative er mechanism in the name of users completely defeats the ease of use and time-saving.
It is very typical of organisations to perform web application (WebApp) security assessments before the go-live of newer applications or periodic assessments of their existing applications
And these assessments are known by all sorts of aliases like application penetration testing (App PenTest), ethical application hacking etc. For those companies lacking the internal core competency of AppSec, often outsource this activity to competent third party players in the market.
What does the CxO function expect post an AppSec assessment? This (the AppSec assessment) is often treated as an additional or ancillary investment to the core development expenditure. The CxO function expects air-tight security within the application after such an assessment. Once the development teams start mitigating actions; one can often hear statements filled with hyper-expectations like ‘the application should now become unhackable’ or ‘no one break the application now & it can go public.’
So why are AppSec tested applications still not secure? In most of the cases applications undergo assessments when they are either almost ready for production or already in production. This is against the spirit of AppSec to begin with, as AppSec is a process that should ideally be invoked right at the inception of the applications SDLC (software development life cycle). Very rarely are AppSec resources involved during the requirement analysis or the finalisation of the design. And therefore the assessment that happens (post development) is more of a corrective activity rather than a proactive one. Flaws and vulnerabilities that could have been killed right at the beginning; are most often patched (with quick hacks & not actual AppSec best practices) after the application is already in production.
THE CHIEF TECHNOLOGY OFFICER FORUM
CTO FORUM 07 JUNE 2012
The rise of mobility is recharging both the enterprise and the employee