Secure SDLC – Core BankingPage 2Agenda► Core Banking and Advantages► What do statistics reveal..► Need for Application Security..► SLDC versus Secure SDLC► Sustaining Secure SDLC Lifecycle► Summary► Questions and Answers
Secure SDLC – Core BankingPage 3Core Banking and Advantages► Core Banking in simple terms means performing centralized bankingoperations and transactions of branches and Head Office typically at DataCentre► This furnishes real-time financial position and situation of bank which furtherenables taking quick decisions in today’s dynamic banking environment► Further, centralization helps better monitoring, analysis and rollout/changes ofany module of application► Extends customer reach to not only nearest branch but also to other branchesand HO (if need be)
Secure SDLC – Core BankingPage 4What do statistics reveal…Application SecurityCore Banking, InternetBanking , Mobile Banking* Over half (51%) of developers andover half (51%) of security personnelhave no training in applicationsecurity.* Close to half (44%) of the developerssurveyed stated there is absolutely nocollaboration between theirdevelopment organization and thesecurity organization when it comesto application security.* Survey conducted by Security Innovation and Ponemon InstituteErnst & Young AdvancedSecurity Center (ASC) findings:► 93% of applications tested haveat least 1 high-risk finding► High risk findings► 70% only require low level ofeffort to exploit► 46% require low level of effort toremediate► 34% could be prevented byproperly validating user input► 33% are Cross-Site Scripting(XSS) or SQL Injection
Secure SDLC – Core BankingPage 5Need for Application Security…► Core Banking : heart of banking operations utmost critical components ofbanks to safeguard and maintain► Stores critical information - customer names, address details, accountinformation etc► Compromise of any of this information has direct implication on regulatoryrequirements and compliance frameworks (such as ISO 27001, CoBIT, PCI-DSS etc.) which also have direct impact on bank’s reputation► Whether developed in-house, purchased from a third party, or supplied by anoutsourcing company, software applications are vulnerable with applicationrelated risks
Secure SDLC – Core BankingPage 6SDLC versus Secure SDLCBusinessRequirementsDesign DevelopmentFunctionalTestingDeploymentBusiness andSecurityRequirementsSecureDesignSecureDevelopmentSecurity &FunctionaltestingSecureDeployment► Typical SDLC does not explicitly include ‘Security’ in it► Secure SDLC has explicit place for ‘Security’ and practices within it
Secure SDLC – Core BankingPage 7Secure SDLCBusiness and Security RequirementsUnderstanding security requirements should be a mandatory exercise of the businessrequirements phase when developing an application. Security requirements in this phaseare:► Application Risk Profiling: Review the Core Banking application portfolio in-terms ofrisk as compared to other applications within Bank. Responses to questions such asbelow will help determining the same:► What are the key business risks and possible technical risks?► Will the application be accessible over Internet► Will the application store personally identifiable information (PII)?► Describe and confirm high level security requirements► What high level data or information needs to be accessed?► What is the context of the application within the current infrastructure?► What application features will have an impact on security?► Determine possible use cases► How will users interact with the application – VPN, Browser etc.?► Will other web services or applications connect with the application?
Secure SDLC – Core BankingPage 8Secure SDLCSecure DesignSecurity MUST begin right from secure design…► Developing Threat Model: Excellent method to determine technical security posture ofproposed application. This can be achieved by:► Decomposing application to determine potential weak spots within application that attackermight want to exploit► Categorizing and rank threats to determine potential threats that can help develop mitigationstrategies► Mitigation for those identified threats such as information security training to developers andprogrammers, programming language specific secure coding trainings etc.► Secure Architecture Design (SAD):► Security architecture framework should be established within Bank that can serve as foundationfor secure design that can be used for multiple application development in-house► Develop Security Test Plans► basis the frequency of testing (Quarterly, monthly), area of tests (Web, APIs etc.,) type of tests(Black or White box)
Secure SDLC – Core BankingPage 9Secure SDLCSecure DevelopmentSecure development is inherent part of developing business logic for core bankingapplications► Program for Developer Awareness and Training:► Common observation that programmers often have very little experience in coding securely► They must undergo adequate training bare essentially for Web application security, languagespecific (.NET, Java) secure coding techniques and custom courses based on code review orapplication tests► Developing Secure Coding Standards, Guidelines and Frameworks for KeyLanguages and Platforms:► Objective is to provide SDLC participants with the proper requirements for securing softwareapplications right from designing stage till deployment► Source Code Review Process:► Control flow analysis in addition to automation of source code review of application must beadopted► To accurately track the sequencing of operations to prevent issues such as un-initializedvariable use or a failure to enable parser validation.
Secure SDLC – Core BankingPage 10Secure SDLCSecurity and Functional TestingSecurity Testing (Vulnerability Assessment, Penetration Testing etc.) should be inherentalong with functional testing of Core Banking applications.► Security Integration with existing test bed:► Most enterprise test environments use automated tools to perform functional, usability and QAtesting► As a matured security testing processes, software testers must be inclined to embraceautomated security tools that link into their existing test beds► Security related regression testing:► Helps in confirming the security view presented by the architecture and development teams► Further it will also present an added level of comfort to internal and external application auditteams► Develop Security Standards for infrastructure supporting the Applications► Develop pre-implementation risk analysis► The combined/overall security of the application should be determined before the applicationgoes live. For e.g., the orchestration of web server farms with multiple operating systems andweb server platforms, the designing of firewall access control lists and assignation of networkports and the integration with application servers can spark off a plethora of innocuous butdangerous vulnerabilities.
Secure SDLC – Core BankingPage 11Sustaining Secure SDLC life-cycleOngoing security has to be ensured in-order to maintain successful Secure SDLC lifecycle► Extremely critical since the application goes numerous changes post its developmentand deployment, which may directly or in-directly affect its pre-determined securityposture.► Following are few suggested activities to ensure ongoing security for core bankingapplications:► External Security Design Reviews► Post-deployment Penetration Tests and Code Reviews► Vendor Risk Management Reviews► Outsourced Software Security Acceptance Testing services► Legacy Application Reviews
Secure SDLC – Core BankingPage 12Summary – Secure SDLC• By definition, theSystem RequirementsSpecification (SRS)document capturesfunctional requirementsonly. Non-functionalrequirements (such assecurity andperformance) are oftennot capturedadequately.• Authentication, AccessControl, SessionManagement, Auditing,Cryptography.• Documentation & reviewof supplementaryspecifications thataddress non-functionalrequirements.• Potential threats andattack scenarios are notenvisaged during thedesign stage.• Security flaws detectedduring the design phasemay incur 30-60 timesless efforts compared tothose detected postrelease.• Authentication, AccessControl, SessionManagement, Auditing,Cryptography.• Secure SDLC Benefits:Threat Modeling, AttackTree Developmentaimed at uncoveringdesign flaws• Unsafe functions andAPIs are used withoutany mitigating controlsas formal secure codingguidelines do not exist.• Where formal securecoding guidelinesexist, they may not beadhered to if thedevelopers do not realizethe value of therestrictive coding rulesowing to lack of securityawareness.• InputValidation, ExceptionHandling, InteractionWith DeploymentEnvironment• Secure SDLC Benefits:Secure CodingHandbook and SecureApplication DevelopmentWorkshops to enhancesecurity awareness.• Testing efforts arefocused on identifyingand fixing functionalitybugs. Security focusedtesting is not carried outas the securityrequirements have notbeen identified anddocumented.• The importance laid ondevelopmentconcentrates talentedworkforce in thoseteams.All• Secure SDLC Benefits:Security focused testingas a result ofdocumented securityrequirements.• Applications are oftengranted privilegedaccess to thedeploymentinfrastructure(OS, RDBMS) in orderto save the effortsinvolved in identifyingthe minimum privilegesrequired at theinfrastructure level tosupport the applicationfunctionality.• Interaction WithDeploymentEnvironment.• Secure SDLC Benefits:Application functionalityguaranteed to work inhardened deploymentinfrastructure.DescriptionSecureSDLCBenefitsSecurityDomains
Secure SDLC – Core BankingPage 13Questions and Answers