Re-Thinking BYOD Policy.pptx

Forget About BYOD: Develop a Realistic Mobile Security Policy

Tom Bain Director, Product Marke4ng Security Innova4on

Who Am I?

•  Director, Product Marke0ng, Security Innova0on

•  Formerly with Q1 Labs (an IBM Company) and Applica0on Security, Inc.

•  Ac0ve blogger, presenter

•  BA, Communica0ons, RIC; MS, Interna0onal Rela0ons/Public Affairs, UMASS

Thomas Bain

Tonight’s Agenda ①  BYOD Dilemma:

Ø Stats/Trends

Ø Biz vs IT Sec Need

Ø Why it’s a security risk

②  Differences Between App & IT Sec Policy

Ø  Incremental policy construc0on

Ø Real-‐world policy improvement

③  Recommenda0ons Ø Steps you should consider

Who We Are Application Security Experts • 10+ Years vulnerability research • Security Tes0ng Methodology adopted by SAP, Microso\, Symantec

• Authors of 8+ books Products and Services • Standards -‐ Best Prac0ces • Educa0on -‐ CBT & Instructor-‐Led • Assessment -‐ So\ware and SDLC

Reducing Application Security Risk • Cri0cal Vulnerability Discovery • Secure SDLC Rollout • Internal Competency Development

I. BYOD: Security Challenges are Emerging

The BYOD Dilemma • Mobile devices help employees increase produc0vity – staying connected is not really op0onal anymore!

•  Usage has experienced a massive up0ck: 60% of today’s workforce is using a smartphone specifically for business use.

•  IT is struggling to keep up with device management.

• Mobility by its nature opens up a larger agack surface with more points of entry.

•  Difficult to measure business need through IT Security lens.

•  Developing a policy isn’t as easy as it might seem. --Mobility Outlook Report, Mobile Enterprise, 2013

Business vs. Security •  Users lose autonomy with security policies that aren’t well-‐defined.

•  Performance + capabili0es o\en trump security = IT headache.

•  Users expect an always-‐on, secure connec0on and func0onality

•  Time to market pressures hurt security: But good architecture and backend systems can help.

•  EX: Frameworks like PhoneGap can get to market quickly: But can introduce new vulnerabili0es

Business Usage Uptick •  84% use the same smartphone for work and for personal usage.

•  81% of employed adults use at least one personally owned electronic device for business (Harris Interac0ve survey, February 2012)

•  59% of employees surveyed use mobile devices to run line-‐of-‐business applica0ons (Ibid)

•  74% of companies allow BYOD usage in some manner (Aberdeen Group, February 2011)

--Experian Mobile Security Survey, November 2012; Harris Interactive, Feb 2012; Aberdeen Group, Feb., 2011

Security Isn’t a Priority •  50% of companies have experienced a data breach due to inadequate device security (Ponemon survey, 2012)

•  47% don’t have a password on their mobile phone.

•  51% stated their companies couldn’t execute a remote wipe if lost or stolen.

•  49% said mobile security has not been addressed with them by IT.

--Experian Mobile Security Survey, November 2012; Harris Interactive, Feb 2012; Aberdeen Group, Feb., 2011

Gartner’s Top 7 Failures in Mobile Device Security

•  Inconsistent security policies •  Laptop encryp0on bypass mode •  Unmanageable devices

•  Shared media leakage • Minimal device management

•  Readable data on disposed-‐of devices

•  Inter-‐applica0on data leakage

-‐-‐Girard, John, Top 7 Failurs in Mobile Device Security,, Gartner, February 2013

Mobile is the Top Security Risk

-‐-‐Efficacy of Emerging Network Security Technologies, Ponemon Research, February 2013

On Pace for Increased Incidents

Why is BYOD a Security Problem? •  Device turn-‐over: What happens to the old device? •  New devices: Default or customized setngs? •  How can you know everything about every device?

•  So\ware updates – user vs IT. •  App Stores: Approved apps?

•  Applica0ons: Ø What data is on your device? Ø What enterprise applica0ons can you connect to?

Ø Which apps are connected to other apps? EX: Your blog app is connected to your CMS, which feeds to Twiger, etc.

Mobile Devices & Data Sources

Mobile Vulnerabilities

Traditional Vulnerabilities

What Are Attackers After?

Verizon Business Data Breach Investigations Report, 2012

II. BYOD: AppSec vs InfoSec Policy

InfoSec vs. AppSec Policy Information Security Application Security

Role Based Receptionist, IT Manager, etc

• Architect, Developer, Tester • Application Roles and Privileges

How to Implement

Rollout and configuration of servers, databases, anti-virus, communications, certificates, etc.

Rollout of web application firewall and secure development best practices • Application Authentication checks • Secure Design components • Attack surface reduction • Code hardening • Data Encryption • Input validation

Expertise Needed to Implement

IT networking, database and computer/OS configuration skills

• How applications interact with environment • How applications function and fail with respect to security • Software development skills w/ security overlay

Policy Statement Comparison •  Network Security Control

Ø Enable SSL on the web server. Ø Don’t transmit sensi0ve data via IM chats. (Actually a policy statement in PCI-‐DSS)

•  Database Security Control Ø Configure DB server so sensi0ve data stores are encrypted.

•  Physical Control Ø Shred documents that contain sensi0ve data.

•  Applica<on Security Control Ø Encrypt sensi0ve data during transmission. Ø Web facing applica0ons must be resilient to SQL injec0on agacks.

Good, Better, Best: ��SQL Injection Policy

✔ MINIMUM Build web applica0ons that defend against SQL injec0on agacks.

✔✔ BETTER Build web applica0ons that defend against SQL injec0on agacks by sani4zing all user input.

✔✔✔ GOOD Build web applica0ons that defend against SQL injec0on agacks by sani0zing all user input using this approved sani4za4on rou4ne.

✔✔✔✔ EXCELLENT …..plus

•  So\ware Developers do X •  So\ware Testers do Y

Good, Better, Best: ��Protect Sensitive Data

✔ MINIMUM Protect sensi0ve data.

✔✔ BETTER Protect sensi0ve data by using this approved encryp4on.

✔✔✔ GOOD Protect sensi0ve data by using this approved encryp0on in databases that store and during transmission of sensi4ve data.

✔✔✔✔ EXCELLENT ….plus

•  Architects define algorithms.

•  Developers never write their own crypto.

•  Test/QA verifies XYZ.

Good, Better, Best: ��Cross-Site Forgery

✔ MINIMUM Create applica0ons that are resilient to Cross-‐Site Request Forgery.

✔✔ BETTER Create so\ware applica0ons that are resilient to CSRF agacks by using the OWASP Top 10 “CSRF Cheat Sheet.”

✔✔✔ GOOD Create so\ware applica0ons that are resilient to CSRF agacks by using the OWASP Top 10 “CSRF Cheat Sheet” and implement a language-‐appropriate framework.

✔✔✔✔ EXCELLENT ….plus

•  Use challenge-‐response. •  QA check reference headers.

Inadequate Example: ��App Pen Testing

•  Policy: •  “Conduct annual tests of internet facing applica0ons.”

•  How to improve it

•  Specify the type of test, e.g., web vulnerability scan, source code review, paper audit, etc.

•  How deep should it go / What should be tested? Ø OWASP Top 10 vulnerabili0es

•  Define the key assets you are trying to protect.

•  Specify which agacks should be conducted. Ø Threat modeling in advance can guide you here.

Inadequate Example: Authentication •  Policy

Ø “Ensure applica0ons processing data properly authen0cate users through central authen0ca0on systems where possible.”

Ø “If addi0onal func0onality is needed, coordinate development with Informa0on Technology Services.”

•  How to improve it Ø Here is our approved authen0ca0on library <URL>. Ø Remove ambiguity.

•  “coordinate with ITS”

•  Rather, obtain wrigen excep0on for using any authen0ca0on mechanism not explicitly approved by InfoSec Office

Ø “where possible”

Inadequate Example: SQL Injection •  Policy

Ø “SQL Injec0on vulnerabili0es must be prevented.” Ø See OWASP SQL_Injec0on_Preven0on_Cheat_Sheet for recommenda0ons.

•  How to improve it Ø Use Parameterized SQL statements and stored procedures.

Ø Use white-‐lis0ng to constrain user input. Ø Use company-‐approved sanita0on library, found here <URL>.

Inadequate Example: Input Validation •  Policy

Ø “Ensure applica0ons validate input properly and restric0vely, allowing only those types of input that are known to be correct.”

Ø …”examples include, but are not limited to, cross-‐site scrip0ng, buffer overflow errors, and injec0on flaws.”

Ø “…see hgp://www.owasp.org for more.”

•  How to improve it Ø Use this input sanita0on rou0ne <URL>. Ø Validate Input from all sources For Type, Length, Format, and Range.

Ø Iden0fy all source of input and verify validators have been used to check input.

Ø User type-‐safe parameters and stored procedures.

III. BYOD: Policy Development to Fit Your Business

Where do I Start? I.  Consider risk scenarios. II.  Adapt from proven or trustworthy

models.

III.  Measure percep0on. IV.  Understand roles, privileges and

what’s in place today. V.  Get granular with your ques0ons &

considera0ons.

VI.  Figure out a strategy for tes0ng your applica0ons.

VII.  Policy enforcement.

VIII. Raise awareness/required training.

Determine Risk Tolerance

•  Take an inventory of your high-‐risk applica0ons/mobile applica0ons.

•  Determine business cri0cality.

• What’s your agack probability? •  How do you define the agack surface?

•  Consider overall business impact. • Where does compliance factor in? • What are the security threats?

Trustworthy Sources

Measure Perception •  Attudes of general popula0on toward security (suppor0ve, antagonis0c, indifferent?)

•  Attudes of general popula0on toward management (suppor0ve, antagonis0c, indifferent?)

•  Attudes of management toward security?

• What’s the percep0on of the current BYOD policy?

•  Have there been related security incidents?

Role-Based Questions • Which departments/groups/individuals have been most ac0ve in developing policies?

•  Has there been any previous collabora0on between policies and authors?

•  Can you iden0fy a poten0al champion(s) to support the new policy?

•  Areas of agreement in commonly implemented controls re: policies?

•  Support documents, materials and related policies should be cited in mobile device policy.

•  Know who has access to what and how they are able to access.

Granularity is Good •  How will mobile devices be used? •  Devices assigned to one person or shared? • Which mobile applica0ons would be used?

• What informa0on is accessible through mobile devices? • What informa0on will be stored on the mobile devices?

•  How will data be shared to/from and between mobile devices? • Who’s ul0mately responsible for mobile devices? • Will personal ac0vi0es on company devices be permiged?

• What levels of support are expected?

Define Your Data •  How sensi0ve is your data? • What kind of data is it? PII, customer data, credit card data, proprietary, IP, etc.

•  Is it subject to regulatory mandates? Which ones?

•  Conduct a threat model: Ø Determine threats

Ø Iden0fy poten0al agacks Ø Understand the frequency & severity with which they are executed.

Rank Your Mobile Apps

Threat Rating

Sensitive Data Lifespan

Compliance Stringency

Customer-Facing

Tier 1 Restricted Long High Yes

Tier 2 Private Mid Medium Yes

Tier 3 Public Short N/A No

Application Criteria

Test Mobile Apps (for Security)

Threat Rating

Static Analysis

Dynamic Analysis

Manual Pen Test

Threat Modeling

Complete/Frequency

Complete/Frequency

Complete/Frequency

Complete/Frequency

Tier 1 Required/Major code changes

Required/Major code changes

Required/Per Milestone

Required/Per Release

Tier 2 Suggested/Monthly

Required/Quarterly

Required/Per Release

Suggested/Per Release

Tier 3 Optional/Quarterly

Required/Annually

Optional/As Needed

Optional/As Needed

Depth, Breadth, Frequency

Summary: Policy Attributes •  Describes contextual, technical guidelines on how security should be integrated within the SDLC Ø By phase, role, technology, applica0on type Ø Leverages internal secure development champion(s) for input

• Maps to compliance mandates

•  Considers cri0cality of applica0on and data Ø Requirements, ac0vi0es and level of detail needed will differ

•  Has clear excep0on policy Ø What if minimum standards can’t be met? What is considered acceptable? Who approves?

•  Includes internally built and third party applica0ons

•  Reflects current maturity and secure development skills Ø The more skilled, the less explicit you need to be with policies

Policy Enforcement •  You need management buy-‐in! •  Broad strategy vs Targeted strategy roll-‐out •  On-‐boarding:

Ø Require all device info as part of hiring process (especially applica0ons)

Ø Require policy training up front •  Require training for various departments:

Ø General popula0on receives awareness training

Ø Technical employees receive in-‐depth training •  Monitor for effec0veness – EX: Deliver training or reminder when employee is out of compliance.

Thank You!! [email protected]

TwiWer: @tmbainjr1

Re-Thinking BYOD Policy.pptx

Technology

Transcript of Re-Thinking BYOD Policy.pptx