Forget About BYOD: Develop a Realistic Mobile Security Policy m Bain ector, Product Marke4ng curity Innova4on
ector, Product Marke0ng, curity Innova0on merly with Q1 Labs (an IBM Company) d Applica0on Security, Inc. 0ve blogger, presenter , Communica0ons, RIC; MS, Interna0onal a0ons/Public Aﬀairs, UMASS Thomas Ba
YOD Dilemma: ts/Trends vs IT Sec Need hy it’s a security risk iﬀerences Between App & IT Sec olicy remental policy construc0on al-‐world policy improvement ecommenda0ons eps you should consider
plication Security Experts + Years vulnerability research curity Tes0ng Methodology adopted by SAP, croso, Symantec thors of 8+ books ducts and Services andards -‐ Best Prac0ces uca0on -‐ CBT & Instructor-‐Led sessment -‐ Soware and SDLC ducing Application Security Risk 0cal Vulnerability Discovery cure SDLC Rollout
ile devices help employees increase uc0vity – staying connected is not y op0onal anymore! ge has experienced a massive up0ck: of today’s workforce is using a rtphone speciﬁcally for business use. struggling to keep up with device agement. ility by its nature opens up a larger ck surface with more points of entry. cult to measure business need ugh IT Security lens. eloping a policy isn’t as easy as it ht seem.
s lose autonomy with rity policies that aren’t well-‐ ned. ormance + capabili0es oen mp security = IT headache. s expect an always-‐on, re connec0on and 0onality e to market pressures hurt rity: But good architecture backend systems can help. Frameworks like PhoneGap get to market quickly: But can
% use the same smartphone for rk and for personal usage. % of employed adults use at st one personally owned ctronic device for business rris Interac0ve survey, ruary 2012) % of employees surveyed use bile devices to run line-‐of-‐ iness applica0ons (Ibid) % of companies allow BYOD ge in some manner (Aberdeen up, February 2011)
% of companies have experienced ata breach due to inadequate ice security (Ponemon survey, 2) % don’t have a password on their bile phone. % stated their companies couldn’t cute a remote wipe if lost or en. % said mobile security has not n addressed with them by IT.
Device Security consistent security policies ptop encryp0on bypass mode nmanageable devices ared media leakage inimal device management eadable data on disposed-‐of evices ter-‐applica0on data leakage
Why is BYOD a Security Problem evice turn-‐over: What happens to the old device? ew devices: Default or customized setngs? ow can you know everything about every device? ware updates – user vs IT. pp Stores: Approved apps? pplica0ons: 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.
Information Security Application Security Based Receptionist, IT Manager, • Architect, Developer, Tester etc • Application Roles and Privileges w to Rollout and Rollout of web application ﬁrewall and secure ement conﬁguration of servers, development best practices databases, anti-virus, • Application Authentication checks communications, • Secure Design components certiﬁcates, etc. • Attack surface reduction • Code hardening • Data Encryption • Input validation ertise IT networking, database • How applications interact with environment ded to and computer/OS • How applications function and fail with respeement conﬁguration skills security • Software development skills w/ security over
Policy Statement Comparison etwork Security Control Enable SSL on the web server. Don’t transmit sensi0ve data via IM chats. (Actually a policy statement in PCI-‐DSS) atabase Security Control Conﬁgure DB server so sensi0ve data stores are encrypted. hysical Control Shred documents that contain sensi0ve data. pplica<on Security Control Encrypt sensi0ve data during transmission. Web facing applica0ons must be resilient to SQL injec0on agacks.
SQL Injection Policy ✔ MINIMUM uild web applica0ons that defend against SQL injec0on agacks. ✔✔ BETTER uild web applica0ons that defend against SQL injec0on agacks by sani4zing all use put. ✔✔✔ GOOD uild web applica0ons that defend against SQL injec0on agacks by sani0zing all use put using this approved sani4za4on rou4ne. ✔✔✔✔ EXCELLENT …..plus • Soware Developers do X • Soware Testers do Y
Protect Sensitive Data MINIMUM otect sensi0ve data. ✔ BETTER otect sensi0ve data by using this approved encryp4on. ✔✔ GOOD otect sensi0ve data by using this approved encryp0on in databases that store and ring transmission of sensi4ve data. ✔✔✔ EXCELLENT plus • Architects deﬁne algorithms. • Developers never write their own crypto. • Test/QA veriﬁes XYZ.
Cross-Site Forgery MINIMUM ate applica0ons that are resilient to Cross-‐Site Request Forgery. BETTER ate soware applica0ons that are resilient to CSRF agacks by using the OWASP TopRF Cheat Sheet.” ✔✔ GOOD ate soware applica0ons that are resilient to CSRF agacks by using the OWASP Top CSRF Cheat Sheet” and implement a language-‐appropriate framework. ✔✔✔ EXCELLENT us Use challenge-‐response. QA check reference headers.
App Pen Testing icy: Conduct annual tests of internet facing applica0ons.” w to improve it pecify the type of test, e.g., web vulnerability can, source code review, paper audit, etc. ow deep should it go / What should be tested? Ø OWASP Top 10 vulnerabili0es eﬁne the key assets you are trying to protect. pecify which agacks should be conducted. Ø Threat modeling in advance can guide you here.
cy Ensure applica0ons processing data properly authen0cate sers through central authen0ca0on systems where ossible.” f addi0onal func0onality is needed, coordinate evelopment with Informa0on Technology Services.” w to improve it ere is our approved authen0ca0on library <URL>. emove ambiguity. “coordinate with ITS” • Rather, obtain wrigen excep0on for using any authen0ca0on mechanism not explicitly approved by InfoSec Oﬃce
cy QL Injec0on vulnerabili0es must be prevented.” e OWASP QL_Injec0on_Preven0on_Cheat_Sheet for commenda0ons. to improve it e Parameterized SQL statements and stored ocedures. e white-‐lis0ng to constrain user input. e company-‐approved sanita0on library, und here <URL>.
olicy “Ensure applica0ons validate input properly and restric0vely, allowing only those types of input that are known to be correc …”examples include, but are not limited to, cross-‐site scrip0ng buﬀer overﬂow errors, and injec0on ﬂaws.” “…see hgp://www.owasp.org for more.” ow 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.
III. BYOD: Policy Development to Fit Your Business
onsider risk scenarios. dapt from proven or trustworthy models. Measure percep0on. nderstand roles, privileges and what’s in place today. et granular with your ques0ons & onsidera0ons. gure out a strategy for tes0ng your pplica0ons. olicy enforcement. aise awareness/required training.
an inventory of your high-‐risk ica0ons/mobile applica0ons. ermine business cri0cality. t’s your agack probability? do you deﬁne the agack surface? sider overall business impact. re does compliance factor in? t are the security threats?
tudes of general popula0on ward security (suppor0ve, agonis0c, indiﬀerent?) tudes of general popula0on ward management (suppor0ve, agonis0c, indiﬀerent?) tudes of management toward urity? at’s the percep0on of the current OD policy? e there been related security dents?
h departments/groups/individuals been most ac0ve in developing ies? here been any previous bora0on between policies and ors? you iden0fy a poten0al champion(s) pport the new policy? s of agreement in commonly emented controls re: policies? ort documents, materials and ed policies should be cited in mobile ce policy. w who has access to what and how
w will mobile devices be used? vices assigned to one person or shared? hich mobile applica0ons would be used? hat informa0on is accessible through mobile devices? hat informa0on will be stored on the mobile devices? w will data be shared to/from and between mobile devices? ho’s ul0mately responsible for mobile devices? l personal ac0vi0es on company devices be permiged? hat levels of support are expected?
sensi0ve is your data? t kind of data is it? PII, customer , credit card data, proprietary, IP, subject to regulatory mandates? ch ones? duct a threat model: termine threats en0fy poten0al agacks nderstand the frequency & severity th which they are executed.
Application Criteria hreat Sensitive Compliance Custo Lifespan ating Data Stringency Faciier 1 Restricted Long High Yeier 2 Private Mid Medium Yeier 3 Public Short N/A No
Depth, Breadth, Frequency reat Static Dynamic Manual Pen Threting Analysis Analysis Test Mode Complete/ Complete/ Complete/ Compl Frequency Frequency Frequency Freque Required/Major Required/Major Required/Per Requireer 1 code changes code changes Milestone Relea Suggested/ Required/ Required/Per Suggesteer 2 Monthly Quarterly Release Relea Optional/ Required/ Optional/As Optioner 3 Quarterly Annually Needed Need
scribes contextual, technical guidelines on how security shouldegrated within the SDLC y phase, role, technology, applica0on type everages internal secure development champion(s) for input ps to compliance mandates nsiders cri0cality of applica0on and data equirements, ac0vi0es and level of detail needed will diﬀer s clear excep0on policy What if minimum standards can’t be met? What is considered cceptable? Who approves? ludes internally built and third party applica0ons ﬂects current maturity and secure development skills he more skilled, the less explicit you need to be with policies
u need management buy-‐in! oad strategy vs Targeted strategy roll-‐out n-‐boarding: Require all device info as part of hiring process (especially applica0ons) Require policy training up front quire training for various departments: General popula0on receives awareness training Technical employees receive in-‐depth training onitor for eﬀec0veness – EX: Deliver training or reminder hen employee is out of compliance.