Dimitrios Stergiou, CISO @ NetEnt addressed a number of traditional approaches to Application Security and discussed their shortcomings at Netlight Edge X breakfast seminar. Edge X breakfast seminars at Netlight are recurring events and talks, held by external speakers as well as employees of Netlight, within topics such as trends, challenges and opportunities within IT and management. He also discussed how the Agile methodology can be combined with an Application Security approach that has been proven to offer the most benefits. He also discussed how the DevOps culture can improve security and some do’s and don’ts when deciding to go down the DevOps path.

1. Application Security
Netlight EDGE

2. Who am I?
• Dimitrios Stergiou (@dstergiou)
• Information Security Manager @ NetEnt
• 7 years InfoSec experience in gaming companies
• 15 years InfoSec experience (engineer, consultant,
manager)
• Mini bio:
• Greek (and Swede)
• Loves: InfoSec, Social Engineering, Economics,
Video games
• Hates: Vegetables, Rain, Pronouncing “j” as “y”

3. Disclaimer
I don’t have the ultimate truth
But I am also NOT trying to sell
you anything
Listen, question and take
everything with a grain of salt

4. Application security placement
•Server
•Custom-developed application
•Server
•Protocols like HTTP, SSH,SMTP
•Router
•TCP,UDP
•Switch
•IP, ARP, ICMP
•Ethernet
•Network cards, fibers, leased lines
In-house code
Application
Transport
Network
Physical

5. What doesn’t
work?
Let’s talk about 4 approaches to
Application Security that don’t
(generally) produce results

6. 4 FAIL approaches to AppSec
Bolt on Security
•Functional first, Security afterwards
•Weakness: Design decisions, long cycle to fix
Waterfall Security
•Prepare every security solution in advance
•Weakness: Not Agile friendly (who does waterfall these days?)
“Random” Security
•Implement every security countermeasure known to man
•Weakness: Expensive, bloats the product / service, time-consuming
All or Nothing Security
•Reactively implement all proposed security controls (usually after an audit)
•Weakness: Too big of a chunk to bite, maybe overdoing it

7. So, what works?

8. Can you recommend a process?
OpenSAMM
Governance
Strategy&
Metrics
Policy &
Compliance
Education&
Guidance
Construction
Security
Requirements
Threat
Assessment
Secure
Architecture
Verification
Design Review
Security
Testing
CodeReview
Deployment
Environment
Hardening
Vulnerability
Management
Operational
Enablement
BSIMM
Governance
Strategy&
Metrics
Policy &
Compliance
Training
Construction
Standards &
Requirements
AttackModels
Security
Features&
Design
Verification
Architecture
Analysis
Security
Testing
CodeReview
Deployment
Software
Environment
Configuration
& Vulnerability
Management
Penetration
testing

9. Conclusion
• We still don’t have an “absolute
truth” – there is no standard for
AppSec
• But these 2 modelslook
EXTREMELYsimilar
• So maybe we have some kind of
consensus on what needs to be
done

10. What are we
trying to
achieve?
• Cover the basis
• Auditrequirements
• Regulatoryrequirements
• Manage risk
• Mitigate,avoid

11. OWASP, They grouped everything!

12. Some basics!
Error handling
•Generic error
messages
• Handle all
exceptions
•Log, log, log
•But don’t log
everything
•Safeguard logs
Data
protection
•HTTP is dead, so
isSSL
• Use TLS
everywhere
•Manage your
cryptokeys
•Avoidstoring
sensitivedata
Authentication
•No hardcoded
credentials
•Proper password
reset system
•Strong password
policy
•Accountlockout
• Watch what you
disclose in error
messages
Input &Output
• Validate
everything
•Whitelists over
blacklists
• Use token for
CSRF protection
• User
parameterized
SQLqueries
• Use Content-
Securityheader
Session
management
•Random session
IDs
•Force idle session
timeouts
• Invalidate
sessionsafter
logout
• Use “secure”
and “httpOnly”
for Cookies
Access control
•Check every
request
•Least privilege
• Avoid direct
objectreferences
• Validate
forwardsand
redirects

13. That is TOO
much!
• How are we going to do all
these things?
• “Do we need a security
project?”

15. Agile &
AppSec
• Bring AppSec activities into
your Agile framework
• Iteration and continuity is key
• Breed new (improved) habits!

16. Exploration
Backlog
Architecture
Spikes
UserStories
Iteration 0
Teamsetup
Processsetup
Infrastructure
setup
Iteration N
Backlog
Grooming
Incremental
Delivery
UserStories
Release
Preparation
AcceptanceTest
Documentation
Release
Publish
SecurityObjectives
MinimSeucmuritVyiable
RePqruoirdemucentts
SecuritySpikes
Vision / Scope
AbuseStories
Threat Abuse
Model Stories
Design Code
Inspect Inspect
Security Security
SRpiektersospecGtoivaels
SecurityTesting
Packaging /
Release
SecurityTesting
Security
Documentation
Security
Retrospective
Typical Agile Organization

17. Latest
nightmare
• Not a bad idea, but…
• … there is a difference
between DevOps and the
“Wild, wild west”

18. Simplified
DevOps
• End-to-end product team
• Responsible for the full
lifecycle of the product
• BUT…

19. Etsy, the
poster boy
(or girl)
• “Invented DevOps”
• Made it a trend
• But…
Fine print:
Etsy built a new, segmented PCI-DSS compliant environment for their payment systems - "we built a whole separate Etsy,
essentially";
In the payments environment they "still have to follow the rules: a developer still doesn't have access to a production
database", but they'll have dbas working alongside them who they can ask for help, and graphs showing metrics from the
database

20. R
E
A
L
I
T
Y

22. Should we DevOps?
Benefits
• Time to market
• Ownership & Culture
• Security actually improves
• Knowledge spread
• Improved product
Caveats
• Without discipline, chaos
• Without automation, chaos
• Jack of all trades, master of none
• Segregation of duties out the door
• Regulators not ready yet

23. What about security, SevDevOps?

24. SecOps
Provide “secure” baselinesfor
the DevOps teams
Pass test results and risk
assessments to DevOpsASAP
Monitor all things – threat
landscape changes by the minute
Deliver security as code