1. Secure SDLC – Core Banking
Eric Anklesaria
Partner – Financial Services – Business Advisory

2. Secure SDLC – Core BankingPage 2
Agenda
► Core Banking and Advantages
► What do statistics reveal..
► Need for Application Security..
► SLDC versus Secure SDLC
► Sustaining Secure SDLC Lifecycle
► Summary
► Questions and Answers

3. Secure SDLC – Core BankingPage 3
Core Banking and Advantages
► Core Banking in simple terms means performing centralized banking
operations and transactions of branches and Head Office typically at Data
Centre
► This furnishes real-time financial position and situation of bank which further
enables taking quick decisions in today’s dynamic banking environment
► Further, centralization helps better monitoring, analysis and rollout/changes of
any module of application
► Extends customer reach to not only nearest branch but also to other branches
and HO (if need be)

4. Secure SDLC – Core BankingPage 4
What do statistics reveal…
Application Security
Core Banking, Internet
Banking , Mobile Banking
* Over half (51%) of developers and
over half (51%) of security personnel
have no training in application
security.
* Close to half (44%) of the developers
surveyed stated there is absolutely no
collaboration between their
development organization and the
security organization when it comes
to application security.
* Survey conducted by Security Innovation and Ponemon Institute
Ernst & Young Advanced
Security Center (ASC) findings:
► 93% of applications tested have
at least 1 high-risk finding
► High risk findings
► 70% only require low level of
effort to exploit
► 46% require low level of effort to
remediate
► 34% could be prevented by
properly validating user input
► 33% are Cross-Site Scripting
(XSS) or SQL Injection

5. Secure SDLC – Core BankingPage 5
Need for Application Security…
► Core Banking : heart of banking operations utmost critical components of
banks to safeguard and maintain
► Stores critical information - customer names, address details, account
information etc
► Compromise of any of this information has direct implication on regulatory
requirements 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 an
outsourcing company, software applications are vulnerable with application
related risks

6. Secure SDLC – Core BankingPage 6
SDLC versus Secure SDLC
Business
Requirements
Design Development
Functional
Testing
Deployment
Business and
Security
Requirements
Secure
Design
Secure
Development
Security &
Functional
testing
Secure
Deployment
► Typical SDLC does not explicitly include ‘Security’ in it
► Secure SDLC has explicit place for ‘Security’ and practices within it

7. Secure SDLC – Core BankingPage 7
Secure SDLC
Business and Security Requirements
Understanding security requirements should be a mandatory exercise of the business
requirements phase when developing an application. Security requirements in this phase
are:
► Application Risk Profiling: Review the Core Banking application portfolio in-terms of
risk as compared to other applications within Bank. Responses to questions such as
below 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?

8. Secure SDLC – Core BankingPage 8
Secure SDLC
Secure Design
Security MUST begin right from secure design…
► Developing Threat Model: Excellent method to determine technical security posture of
proposed application. This can be achieved by:
► Decomposing application to determine potential weak spots within application that attacker
might want to exploit
► Categorizing and rank threats to determine potential threats that can help develop mitigation
strategies
► Mitigation for those identified threats such as information security training to developers and
programmers, programming language specific secure coding trainings etc.
► Secure Architecture Design (SAD):
► Security architecture framework should be established within Bank that can serve as foundation
for 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)

9. Secure SDLC – Core BankingPage 9
Secure SDLC
Secure Development
Secure development is inherent part of developing business logic for core banking
applications
► 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, language
specific (.NET, Java) secure coding techniques and custom courses based on code review or
application tests
► Developing Secure Coding Standards, Guidelines and Frameworks for Key
Languages and Platforms:
► Objective is to provide SDLC participants with the proper requirements for securing software
applications right from designing stage till deployment
► Source Code Review Process:
► Control flow analysis in addition to automation of source code review of application must be
adopted
► To accurately track the sequencing of operations to prevent issues such as un-initialized
variable use or a failure to enable parser validation.

10. Secure SDLC – Core BankingPage 10
Secure SDLC
Security and Functional Testing
Security Testing (Vulnerability Assessment, Penetration Testing etc.) should be inherent
along 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 QA
testing
► As a matured security testing processes, software testers must be inclined to embrace
automated 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 audit
teams
► 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 application
goes live. For e.g., the orchestration of web server farms with multiple operating systems and
web server platforms, the designing of firewall access control lists and assignation of network
ports and the integration with application servers can spark off a plethora of innocuous but
dangerous vulnerabilities.

11. Secure SDLC – Core BankingPage 11
Sustaining Secure SDLC life-cycle
Ongoing security has to be ensured in-order to maintain successful Secure SDLC lifecycle
► Extremely critical since the application goes numerous changes post its development
and deployment, which may directly or in-directly affect its pre-determined security
posture.
► Following are few suggested activities to ensure ongoing security for core banking
applications:
► External Security Design Reviews
► Post-deployment Penetration Tests and Code Reviews
► Vendor Risk Management Reviews
► Outsourced Software Security Acceptance Testing services
► Legacy Application Reviews

12. Secure SDLC – Core BankingPage 12
Summary – Secure SDLC
• By definition, the
System Requirements
Specification (SRS)
document captures
functional requirements
only. Non-functional
requirements (such as
security and
performance) are often
not captured
adequately.
• Authentication, Access
Control, Session
Management, Auditing,
Cryptography.
• Documentation & review
of supplementary
specifications that
address non-functional
requirements.
• Potential threats and
attack scenarios are not
envisaged during the
design stage.
• Security flaws detected
during the design phase
may incur 30-60 times
less efforts compared to
those detected post
release.
• Authentication, Access
Control, Session
Management, Auditing,
Cryptography.
• Secure SDLC Benefits:
Threat Modeling, Attack
Tree Development
aimed at uncovering
design flaws
• Unsafe functions and
APIs are used without
any mitigating controls
as formal secure coding
guidelines do not exist.
• Where formal secure
coding guidelines exist,
they may not be adhered
to if the developers do
not realize the value of
the restrictive coding
rules owing to lack of
security awareness.
• Input Validation,
Exception Handling,
Interaction With
Deployment
Environment
• Secure SDLC Benefits:
Secure Coding
Handbook and Secure
Application Development
Workshops to enhance
security awareness.
• Testing efforts are
focused on identifying
and fixing functionality
bugs. Security focused
testing is not carried out
as the security
requirements have not
been identified and
documented.
• The importance laid on
development
concentrates talented
workforce in those
teams.
All
• Secure SDLC Benefits:
Security focused testing
as a result of
documented security
requirements.
• Applications are often
granted privileged
access to the
deployment
infrastructure (OS,
RDBMS) in order to
save the efforts
involved in identifying
the minimum privileges
required at the
infrastructure level to
support the application
functionality.
• Interaction With
Deployment
Environment.
• Secure SDLC Benefits:
Application functionality
guaranteed to work in
hardened deployment
infrastructure.
Description
SecureSDLC
Benefits
Security
Domains

13. Secure SDLC – Core BankingPage 13
Questions and Answers

14. Thank You!
Email: Eric.Anklesaria@in.ey.com