Achieving Hi-Fidelity Security by Combining Packet and Endpoint Data
ISACA 2016 Annual Conference SA_State of Risk_Tunde Ogunkoya_DeltaGRiC_Consulting30.09.2016
1. State of Risks (Cyber, Legal, Operational) in Business
Critical Applications; Commercial Software Vs Open Source’
Tunde Ogunkoya
2. Introduction
History into Applications /Code (in summary)
Who is responsible for Security in Applications? Dev Team? Security? Business?
Trends Today – 2016!
Commercial Software: SAP as a point of focus (Why SAP?)
Open Source Security, The challenges today; Security, Legal, Operational
What can be done to solve the problem?
Agenda
3. Consulting Partner, DeltaGRiC Consulting – Leading Consultancy in the SAP
Africa Ecosystem, focusing on mitigating cyber Risk and Compliance violations in
SAP run organizations
Enterprise Application Security Enthusiast/Evangelist – Focused on SAP and
Open Source Software Security.
Delivered first ever SAP cybersecurity project on the African Continent - RSSC,
Swaziland with ERPScan team
Respected opinion on SAP Security matters / OSS Security matters (Times
News, ITWeb)
Advocate of “Compliance is only but a check-in-the-box” and does NOT really
mitigate the actual Security Risks.
Participated in the Curriculum content development for the Graduate Program in
Cyber Security & Intelligence at the Ontario College of Management and
Technology, Canada (OCMT).
I am not an Expert !.I know one thing: that I know nothing … Apology 29d
Socrates
Introduction
4. How it all began with Applications
Ada Lovelace 19th Century – Analytic Engine – Never saw the light of day
Alan Turin (23 June 1912 – 7 June 1954).
Margaret Hamilton – 1969.
Microsoft, SAP, Oracle, IBM, …etc
Ofcourse Open source has
always been around for days!! ,
The Past often leads us to our NOW …FUTURE?
But the Focus ?
Network Layer – SANS
Host Layer
Physical Layer
SIEM
A little Web Application Sec
SABSA/
TOGAF…Omits ASVS
6. SAP / Hadoop / Oracle/ Microsoft/ Odoo / *&^$#
The wide-spread myth that Business critical Application Security especially ERP is limited to SOD matrix
has been dispelled.
Application languages come in various flavours - ABAP, C#, C++, JAVA, which exists in almost every
company – A lot of the times, they can store program vulnerabilities left by unqualified developers or
special backdoors which can help insiders to gain illicit access to business data.
=
Of all the recorded cyber breaches that occurred in 2015, 50% was attributed to the Application layer. A
variety of hack tools has been released that prove the possibility of SAP attacks and simplify them for
cybercriminals.
Most of these vulnerabilities allow an unauthorized user to gain access to all the critical business data,
so it is necessary to think about implementing a specific system of SAP security. Unfortunately, many
information security officers are scarcely informed about the security of business applications like SAP &
Oracle.
Commercial Vs Open Source
7. Who is responsible for Security ?
Commercial Code Open Source Code
• “Dedicated security researchers”
• Alerting and notification infrastructure
• Regular patch updates
• Dedicated support team with SLA
• “community”-based code analysis
• Monitor newsfeeds yourself
• No standard patching mechanism
• Ultimately, you are responsible
8. A company hire experts for VAPT service or Product
Those specialists run some pentesting tools
They (may) manually test vulnerabilities, escalate privileges and as a result write report about
vulnerabilities.
“we found vulnerability X on the server Y. Look at the black screenshot with command line”.
Everybody know that there are vulnerabilities in almost every system
how dangerous are they?
how easy is to exploit them?
what can happen after the exploitation?
and what kind of REAL risks to YOUR organization it provides.
Application Security Trends
Credits: Alexander Polyakov
10. A deep Dive into why SAP?
Why SAP?
SAP holds the corporate 'Crown Jewels':
* 290,000 corporate customers, including; 87% of the global 2000; 98% of the most
valued brands
* SAP touches
74% of all global transactions
US$16 Trillion of retail sales
.......and this data and information is of interest and real value to:
Criminal hackers and activists; Competitors, partners and nation states
Unhappy employees and contractors
11. A deep Dive into why Open Source?
“By 2016, Open Source
Software will be included in
mission-critical applications
within 99% of Global 2000
enterprises.”
Will face problems because
of no policy.
50%
10%
30%
80%
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
2010 2014 2018
Open Source as % of G2000
Codebase
Reference: Gartner, Inc.
12. Three Areas of SAP Security :
Business Logic Area : SOD , Access Controls, Insiders
Source Code Security: Developers Mistakes or even Sabotage plans, Insiders
Application Platform Security: External, Over Network; Hackers, Web Services, Mobility, Portal for
Partners, etc.
Myths Vs Facts – Commercial (SAP as a reference point)
13. Possible Exposed SAP Servers
in Africa
South Africa, Kenya, Nigeria
ShodanHQ Search: SAP
Google Search: SAP inurl:cmd=login
Google Search: peoplesoft inurl:cmd=login
Our Findings:
• Close to 200 SAProuters were found on
Shodan and 72% of them vulnerable to
remote code execution
• Most popular release (35%) is still
NetWeaver 7.0, and it was released in
2005.
• One third of Internet-facing SAP web
services does not use SSL at all.
• Major Bank in Africa, Major Airline in
Africa Vulnerable, Government portal
and Automotive company
May, 2015
Continuous Public Publishing
of Vulnerabilities
Global Security Researchers
BUT
No Pentest Information Available
CVE?
CVSS ??
Risk Prioritization
• CVE’s common identifiers enable
data exchange between security
products and provide a baseline
index point for evaluating coverage
of tools and services
• CVSS, is a vulnerability scoring
system designed to provide an open
and standardized method for rating
IT vulnerabilities. CVSS helps
organizations prioritize and
coordinate a joint response to
security vulnerabilities by
communicating the base, temporal
and environmental properties of a
vulnerability
16. The Challenges
SAP Cyber-Security GAP
Management often has
a false sense of
confidence that they
have SAP covered,
while cybersecurity
teams feel they have
little to no visibility into
SAP. It was also
apparent that the SAP
cyber-security gap is
becoming more
ambiguous because of
asset mapping issues –
who houses the
“crown jewels” are
being secured on a
daily basis..
SAP Patch Management Debacle
On average all companies
are working with an 18-
month window of
vulnerability timeline.
This window starts with
the time a vulnerability is
found to when a patch is
issued by SAP and finally
deployed by the
organization itself.
Deployment is still the
biggest problem
organizations face. In fact
- SAP has issued over
3300 patches in total
with 391 issued in 2014
alone. That is 30+ per
month on average. With
approximately 46% of
patches ranked as
“critical” it’s difficult for
an organization to
prioritize their patches
without disruption to the
business.
Misconfiguration
Companies are having
a very difficult time
keeping track of how
systems are
configured let alone
understanding their
entire SAP landscape.
An organization’s
“Crown Jewels” reside
within SAP and
misconfigured SAP
systems and portals
are open targets for
any adversary. Even if
systems have the
latest patch installed,
a misconfiguration
will allow hackers to
access key
information and
business processes. In
most cases, an
attacker’s presence
will go unnoticed for
months.
HANA / IoT
Organizations are moving to the
new de-facto database server
HANA for new SAP solutions. This
changes everything as
organizations cannot view SAP as a
“legacy” system. Organizations
have also been told that with
HANA they will be
more secure, however the fact is
that since 2014 there’s been a
450% increase in new security
patches and with 82% considered
“high priority”. Additionally as
organizations continue to advance
their SAP systems with rapid
application development, mobile
deployments and connecting a
multitude of different devices
(think vending machines, water
meters, etc) to SAP via open APIs
an organization’s SAP attack
surface is expanding at a rapid
pace let alone the complexity of
managing security risks.
19. Open Source -The Challenges
Delivered Code
…and absorbed into
final code.
Internally
Developed
Code
Outsourced
Code
Legacy
Code
Reused Code/
Containers
Supply
Chain
Code
Third Party
Commercial
Code
Open Source
Code
Open source
code introduced
in many ways…
20. What do these Vulnerabilities have in common?
Heartbleed Shellshock GhostFreak Venom
Since:
Discovered:
2011
2014
1989
2014
1990’s
2015
2000
2015
2004
2015
Discovered by:
Component: OpenSSL
Riku, Antti,
Matti,
Mehta
Bash
Chazelas
OpenSSL
Beurdouche
GNU C library
Qualys
researchers
QEMU
Geffner
21. Increasing number of OSS Vulnerabilities
Reference: Black Duck Software knowledgebase, NVD, VulnDB
0
500
1000
1500
2000
2500
3000
3500
2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015
Open Source Vulnerabilities Reported Per Year
nvd vulndb-exclusive
22. Easy access to code
Exploits readily availableVulnerabilities are public
• Used everywhere
24. Automated tools miss most open source Vulnerabilities
All possible
security vulnerabilities
Identifiable
with
Static
Analysis
Identifiable
with Dynamic
Analysis
SAST and DAST
only discover
common
vulnerabilities
Undiscovered
vulnerabilities are
too complex,
nuanced
3,000+ disclosed
in 2014, <1%
found by
automated tools
26. How are companies addressing this today? Not well
Manual tabulation
• Architectural Review Board
• At end of SDLC
• High effort and low accuracy
• No controls
Spreadsheet-based
inventory
• Dependent on developer
best effort or memory
• Difficult maintenance
• Not source of truth
Tracking vulnerabilities
• No single responsible entity
• Manual effort and labor
intensive
• Unmanageable (11/day)
• Match applications,
components & versions with
vulnerabilities
Vulnerability detection
• Run monthly/quarterly
vulnerability assessment
tools (e.g., Nessus,
Nexpose) against all
applications to identify
exploitable instances
27. Recommendations to Solving … SAP Perspective
Compliance
violations
WhiteBox Black Box ABAP/J2EE
SoD Application Platform Z-Program
Make a plan for a Continuous Monitoring on
SAP landscape – Tools that understand SAP
traffic
28. Recommendations to Solving
Choose Open
Source
Inventory
Open Source
Map Existing
Vulnerabilities
Track New
Vulnerabili
ties
Maintain accurate list
of open source
components
throughout the SDL
Identify vulns
during
development
Alert new vulns in
production apps
Proactively choose
secure, supported
open source
TRUST VERIFY MONITOR
29. With IoT, the attack surface automatically doubles every 17 months.
Protecting SAP from cyberthreats begins with a shift in beliefs about accessibility,
vulnerability and responsibility. A cybersecurity program is only effective when it
begins with the appreciation that everything is now connected and therefore
accessible. SAP systems and applications, whether in development or production,
are as much at stake as any other system.
Extending the same (or better) assessments, auditing procedures and tests that
you would for any other enterprise platform or application is no different when you
consider your valuable investments in and reliance on ERP systems such as SAP.
Know what lies in your code – Open Source
Real Attack Surface = Number of critical Web Applications X Average
number of Vulnerability per web Application
In Conclusion
30. Question(s)?
G17, PineWood Office Park, 24 Mabinuori, Shangisha
Woodnmead Magodo Estates
JHB, South Africa Lagos - Nigeria
T: +27 11 083 9828 |+1 408 641 4307 | +27 60 658 7180
info@deltagricconsulting.com
www.deltagricconsulting.com
Thank You
Notas del editor
Disclaimer ! I am not an Expert .. According to Socrates: I know that I know nothing" or "I know one thing: that I know nothing", sometimes ...Apology 29d,
We cannot deny that the application Security challenges are not limited to one side of the divide, infact, the challenges are that : There is a growing attack surface on a daily basis, and organizations are beginning to look for answers to the salient questions they never used to in the past : Questions like: what apps are people running in the organization, How do I set internal policy requirements for application security, is my private or sensitive data exposed over apps, and lastly who is developing those apps?
Also with newer deployment models like containers, we need to ask ourselves : how do we test our applications and what do we actually test?
Big Idea: With commercial 3rd party components there is a support infrastructure build to ensure security patches are applied in a timely manner. The simply does not exist with open source libraries and components – you are mostly on your owner there.
Question: What’s your companies process / policy for implementing security patches, in general AND is there a similar policy for open source?
Disclaimer: There is no intention to badmouth any OEM in this discussion but to point out places of research and our skill area . This is not necessarily a SAP problem but an Applications problem. The Risks could manifest itself from many places : Espionage from other countreis e.g. Spy leaks, Sabbotage e.g DDOS, Modification of Financial Data, Access to networks SCADA in Manufacturinbg environmens and ofcourse: white collar organised fraud.
Open Source has passed its tipping point
Also you need to know that :
Price of Vulnerability is quite low. Besides the fact that patching can be a nightmare .
Also it is somewhat easier to build payload and interconnectivity is also getting better in Africa as well. South Africans may argue with me but I promise you in Nigeria- data looks up to you here.
We think the May 2016 Standard bank Hack was an SAP attack . But since forensics report isn’t out as at yet, we rather not talk about it .
Big Idea: We’ve seen a trend recently in “named vulnerabilities”, and Heartbleed, Shellshock, Freak and the others are likely familiar to you.
Question: What do these all have in common?
Answers we are looking for:
Each is a vulnerability in a widely used open source component
Each existed for years without being detected by automated analysis tools and penetration testing methods.
Each was ultimately identified and disclosed by security researchers conducting manual code reviews.
Big Idea #2: If automated security analysis tools and penetration testing tools were effective at finding vulnerabilities in open source, these vulnerabilities would have been found long ago.
Big Idea: Both good and bad researchers are combing open source looking for vulnerabilities and In 2015 over 3,000 new vulnerabilities were disclosed in the National Vulnerability Database and VulnDB, a proprietary database licensed by Black Duck. As more vulnerabilities are disclosed, code once was believed to be secure, may now be vulnerable
Question: if you can’t reliably track the open source used in your software, how do respond to these new vulnerabilities in your code base? Static analysis tools build in “rules” for the most well known vulns – how would you find the rest?
Big Idea: Open source is not more or less secure than commercial code, but these characteristics simply make it a VERY attractive target for attackers - 1. It’s ubiquitous, so the change of a bad actor finding an addressable target is much higher than with commercial code 2. The source code is available on the public internet – allowing hackers to pick it apart looking for exploitable holes. 3. Using the NVD and OSVBD (among other sources) attackers can find specifics on vulnerabilities to attack and details on how to exploit them, often exploits themselves are published. 4. If they still need help, youtube videos explaining the exploits and how to deploy them are readily available.
Question: The latest high profile vulnerability, GlibC, was made public in February – have you been able to track down where it exists in your environment? How did you / would you accomplish that?
Big Idea: No one technique can find every vulnerability – this is why many security teams deploy both Static and Dynamic analysis tools. In many cases we’ve seen team deploy more than just one dynamic analysis tool.
Question: Importantly, these tools have been used to scan open source code for years – and they did not find the vulnerabilities we’ve been hearing about recently like Heartbleed, GLibC and Drown – why do you think that is?
(Answer you’re looking for here is they require the eyes of specialized human researchers who can look at code, see something that looks “off” and run experiments to determine there is a vuln)
Big Idea: Companies that are addressing open source vulnerabilities typically have a heavy, costly manual process to address it. And at the end of the day, it’s still error-prone and leaves a lot of risk on the table. Companies that choose not to address it at all expose themselves to even greater risk.
Question: What’s your current approach? Is it process-heavy or light? What kind of residual risk do you think you are exposed to?
Big Idea: Most manual processes and most open source management solutions can create a list of open source components and match them with known security vulnerabilities, but to solve the problem holistically, you might want to think about what happens BEFORE, meaning how you would proactively choose the right open source components, as well as what happens AFTER deployment, where you need to monitor whether deployed applications are impacted by new vulns as they are discovered.
Question: Which pieces of a potential solution do you have already and which are you missing?
----------------------------------------------------------------------------------------------------------------
A best-practices solution would combine elements of TRUST, VERIFICATION, and MONITORING:
1 – Starting with TRUST, this is providing developers and architects a way to choose open source components that are free of known vulnerabilities, and have active community support. This is a proactive step that reduces risk downstream in the software development process, and is the most cost-effective means of risk reduction.
2 – VERIFICATION means two things, having an accurate inventory of open source and being able to map than against all known vulnerabilities, in any and all applications, at any point in the SDL
3 – MONITOR means being able to monitor the released code for newly discovered vulnerabilities and alert the right people for remediation.
Many organizations end security testing when applications are released. After all, the code base isn’t changing, nor are the security rules in the tools, so why test simply to see the same results again? However, this ignores the fact that while the code base isn’t changing, the threat environment changes constantly. With over 4,000 new vulnerabilities each year, a comprehensive solution should be continuously monitoring this constant stream of new vulnerabilities, and automatically notify you of any new vulnerabilities in the open source you used in deployed applications, including:
Which applications use the code
How critical the vulnerability is, and
How to remediate it
Big Idea: Most manual processes and most open source management solutions can create a list of open source components and match them with known security vulnerabilities, but to solve the problem holistically, you might want to think about what happens BEFORE, meaning how you would proactively choose the right open source components, as well as what happens AFTER deployment, where you need to monitor whether deployed applications are impacted by new vulns as they are discovered.
Question: Which pieces of a potential solution do you have already and which are you missing?
----------------------------------------------------------------------------------------------------------------
A best-practices solution would combine elements of TRUST, VERIFICATION, and MONITORING:
1 – Starting with TRUST, this is providing developers and architects a way to choose open source components that are free of known vulnerabilities, and have active community support. This is a proactive step that reduces risk downstream in the software development process, and is the most cost-effective means of risk reduction.
2 – VERIFICATION means two things, having an accurate inventory of open source and being able to map than against all known vulnerabilities, in any and all applications, at any point in the SDL
3 – MONITOR means being able to monitor the released code for newly discovered vulnerabilities and alert the right people for remediation.
Many organizations end security testing when applications are released. After all, the code base isn’t changing, nor are the security rules in the tools, so why test simply to see the same results again? However, this ignores the fact that while the code base isn’t changing, the threat environment changes constantly. With over 4,000 new vulnerabilities each year, a comprehensive solution should be continuously monitoring this constant stream of new vulnerabilities, and automatically notify you of any new vulnerabilities in the open source you used in deployed applications, including:
Which applications use the code
How critical the vulnerability is, and
How to remediate it