“We make it a big deal in the company”: Security Mindsets ... · velopment and testing practices since even the best imple-mented cryptography can be subverted by the awed im-plementation

Open access to the Proceedings of the Fourteenth Symposium

on Usable Privacy and Security is sponsored by USENIX

ldquoWe make it a big deal in the companyrdquo Security Mindsets in Organizations that Develop

Cryptographic ProductsJulie M Haney and Mary F Theofanos National Institute of Standards and Technology

Yasemin Acar Leibniz University Hannover Sandra Spickard Prettyman Culture Catalyst

httpswwwusenixorgconferencesoups2018presentationhaney-mindsets

This paper is included in the Proceedings of the Fourteenth Symposium on Usable Privacy and Security

August 12ndash14 2018 bull Baltimore MD USA

ISBN 978-1-939133-10-6

We make it a big deal in the company Security Mindsetsin Organizations that Develop Cryptographic Products

Julie M Haney1 Mary F Theofanos1 Yasemin Acar2 Sandra Spickard Prettyman3

1National Institute ofStandards and Technology

juliehaneymarytheofanosnistgov

2Leibniz University Hannoveracarsecuni-hannoverde

3Culture Catalystsspretty50icloudcom

ABSTRACTCryptography is an essential component of modern comput-ing Unfortunately implementing cryptography correctly isa non-trivial undertaking Past studies have supported thisobservation by revealing a multitude of errors and devel-oper pitfalls in the cryptographic implementations of soft-ware products However the emphasis of these studies wason individual developers there is an obvious gap in morethoroughly understanding cryptographic development prac-tices of organizations To address this gap we conducted 21in-depth interviews of highly experienced individuals rep-resenting organizations that include cryptography in theirproducts Our findings suggest a security mindset not seenin other research results demonstrated by strong organiza-tional security culture and the deep expertise of those per-forming cryptographic development This mindset in turnguides the careful selection of cryptographic resources andinforms formal rigorous development and testing practicesThe enhanced understanding of organizational practices en-courages additional research initiatives to explore variationsin those implementing cryptography which can aid in trans-ferring lessons learned from more security-mature organiza-tions to the broader development community through edu-cational opportunities tools and other mechanisms Thefindings also support past studies that suggest that the us-ability of cryptographic resources may be deficient and pro-vide additional suggestions for making these resources moreaccessible and usable to developers of varying skill levels

1 INTRODUCTIONIn a dynamic threat-laden and interconnected digital envi-ronment cryptography protects privacy provides for ano-nymity ensures the confidentiality and integrity of com-munications and safeguards sensitive information Giventhe need for cryptography there is an abundance of cryp-tographic algorithm and library choices for developers wish-ing to integrate cryptography into their products and ser-vices However developers often lack the expertise to navi-

Copyright is held by the authorowner Permission to make digital or hardcopies of all or part of this work for personal or classroom use is grantedwithout feeUSENIX Symposium on Usable Privacy and Security (SOUPS) 2018August 12ndash14 2018 Baltimore MD USA

gate these choices resulting in the introduction of securityvulnerabilities [27] A 2016 industry survey that includedover 300000 code assessments found that 39 of those ap-plications had cryptographic problems [72] Implementingcryptography correctly is a non-trivial undertaking

In 1997 security expert Bruce Schneier commented on thelack of cryptographic implementation rigor and expertise atthat time asserting ldquoYou canrsquot make systems secure bytacking on cryptography as an afterthought You have toknow what you are doing every step of the way from con-ception to installationrdquo [61] Past studies have supportedthis observation by revealing a multitude of errors in thecryptographic implementations of software products (eg[17ndash19 42]) and the pitfalls developers encounter when in-cluding cryptography within products (eg [1248]) Thisbody of research suggests that developers have not pro-gressed much in the past 20 years However as these stud-ies have been largely focused on individual practices out-side the professional work context or on the developmentof mobile apps it is unclear if these shortcomings also ap-ply to organizational development and testing particularlyamong organizations for which security and cryptographyare essential components One exploratory survey exam-ined high-level organizational practices in cryptographic de-velopment but lacked rich insight into actual practices andmotivators behind those [31] Clearly there is a gap in theliterature in more thoroughly understanding organizationalcryptographic development practices

To address this gap we performed a qualitative investigationinto the processes and resources that organizations employto ensure their cryptographic products are not fraught witherrors and vulnerabilities We define the scope of crypto-graphic products as those implementing cryptographic al-gorithms or using crypto (cryptography) to perform somefunction We conducted 21 in-depth interviews involvingparticipants representing organizations that develop eithera security product that uses cryptography or a non-securityproduct that heavily relies on cryptography Unlike previ-ous studies our participants were professionals who werehighly experienced in cryptographic development and test-ing not computer science students or developers with littlecryptographic experience

The study aimed to answer the following research questions

Q1 What are the cryptographic development and testingpractices of organizations

USENIX Association Fourteenth Symposium on Usable Privacy and Security 357

Q2 What challenges if any do organizations encounter whiledeveloping and testing these products

Q3 What cryptographic resources do these organizationsuse and what are their reasons for choosing these

Our findings went deeper than uncovering practices reveal-ing a security mindset not noted in other research resultsWe discovered that some organizations believe they haveachieved the expertise and rigor recommended by SchneierCompared to developer populations studied in the past theorganizations in our investigation appear to have a strongersecurity culture and are more mature in their cryptogra-phy and security experience The strong security culture weobserved does not appear to be linked to company size oravailable resources These security mindsets permeate theentire development process as they inform judicious selec-tion of cryptographic resources and rigorous developmentpractices

Our work has several contributions To our knowledge thisis the first in-depth study to explore cryptographic develop-ment practices and security mindsets in organizations fromthe viewpoint of those with extensive experience in the fieldWhile some of the practices identified in our study may beconsidered known best practice within the security commu-nity our paper is novel in that there are few research studiesdocumenting occurrences of strong security culture and de-velopment in actual practice and none within the cryptogra-phy context Our study provides systematic scientific vali-dation to the anecdotal point often made by security expertsthat there is no magical one-dimensional solution to crypto-graphic development Rather good crypto is the result of aconcerted effort to build expertise and implement secure de-velopment practices The enhanced understanding encour-ages additional research initiatives to explore variations inthose implementing cryptography This can aid in trans-ferring lessons learned from more security-mature organiza-tions to the broader development community through edu-cational opportunities tools and other mechanisms Ourfindings also support past studies that suggest that the us-ability of cryptographic resources may be deficient and pro-vide additional suggestions for making these resources moreaccessible and usable to developers of varying skill levels

2 RELATED WORKTo provide context this section begins with a brief overviewof cryptographic standards and certifications frequently ref-erenced in our interviews We then underpin our assertionthat cryptographic development is not a trivial undertakingby summarizing past research on crypto misuse and lack ofcrypto resource usability We also present an overview ofprior work on lack of security mindsets and secure develop-ment practices to serve as a contrast to the more security-conscious approaches of our study organizations

21 Cryptographic StandardsCryptographic algorithm standards are developed by con-sensus of community stakeholders (eg vendors researchersgovernments) to foster compatibility interoperability andminimum levels of security These can be found in formalstandards documents from organizations such as Instituteof Electrical and Electronics Engineers (IEEE) [35] Inter-national Organization for Standardization (ISO) [36] and

the US National Institute of Standards and Technology(NIST) [52] Likely due to the US locations of most of thestudy organizations the participants most often mentionedcryptographic requirements issued by NIST As perhaps thebest known government standard the Federal InformationProcessing Standards Publication (FIPS) 140-2 ldquospecifiesthe security requirements that will be satisfied by a crypto-graphic module utilized within a security system protectingsensitive but unclassified informationrdquo [49] These require-ments are mandatory for cryptographic products purchasedby the US Government but also are used voluntarily out-side the government There are two certification programsassociated with FIPS 140-2 [50 51] Under these programsvendors may submit cryptographic algorithm and moduleimplementations for validation testing to accredited testinglaboratories

22 Cryptographic MisuseNumerous studies have highlighted the difficulty developershave in correctly implementing cryptography In 2002 Gut-mann observed that security bugs were often introduced bysoftware developers who did not understand the implicationsof their choices [30] Nguyen showed that even open-sourceimplementations under public scrutiny have cryptographicflaws [53] Lazar performed a systematic study of 269 cryp-tographic vulnerabilities in the Common Vulnerabilities andExposures (CVE) database noting that 17 of bugs werein cryptographic libraries and the remaining 83 were in in-dividual applications usually due to cryptographic librarymisuses [40] Georgiev et al discovered rampant misuse ofSecure Sockets Layer (SSL) in security-critical applicationsdue to poorly designed application programming interfaces(APIs) [25] Fahl et al analyzed 13500 Android apps andfound that 8 were susceptible to man-in-the-middle at-tacks [19] Using static analysis Egele et al found similarissues observing that 88 of over 11000 examined Androidapps contained a significant error in their use of a cryp-tographic API [18] Li et al analyzed 98 apps from theApple App Store and found 64 (653) that contained cryp-tographic misuse flaws [42]

23 Usability of Cryptographic ResourcesUsability is often neglected in cryptographic resources suchas standards and libraries resulting in complex solutionsthat provide little assistance to developers in making securechoices [27 48] Several research groups attempted to rem-edy this by developing tools eg OpenCCE [4] Crypto-Assistant [23] and Crypto Misuse Analyzer [64] to guidedevelopers in choosing and integrating appropriate cryp-tographic methods Others proposed more usable crypto-graphic libraries Forler et al developed libadacrypt a cryp-tographic library created to beldquomisuse-resistantrdquo [20] Bern-stein et al created the Networking and Cryptography li-brary (NaCl) [8] a cross-platform cryptographic library de-signed to avoid errors found in widely used cryptographiclibraries like OpenSSL [55] Acar et al conducted a usabil-ity study of cryptographic APIs that revealed that in ad-dition to usable interfaces clear documentation with codesamples and support for common cryptographic tasks wereimportant in aiding developers [1]

24 Security Development and MindsetThere is much to learn from an examination of secure de-

358 Fourteenth Symposium on Usable Privacy and Security USENIX Association

velopment and testing practices since even the best imple-mented cryptography can be subverted by the flawed im-plementation of another system component McGraw ad-vocated for security to be integrated into all aspects of thesoftware development lifecycle [43] Several documents forexample the Microsoft Security Development Lifecyle [34]and the System Security Engineering Capability MaturityModel (SSE-CMM) [44] formally define secure developmentpractices More recently the Open Web Application Secu-rity Project (OWASP) Secure Software Development Lifecy-cle project is working towards providing guidelines for weband application developers [54] However none of these re-sources specifically mentions considerations for cryptogra-phy

Not surprisingly the implementation of formal secure de-velopment processes is not an easy task A 2016 Veracodesurvey of over 350 developers indicated that organizationsare prevented from fully implementing a secure developmentprocess due to a variety of challenges including security test-ing causing product timeline delays complexity in support-ing legacy security processes security standards and policiesvarying across the organization and developers not consis-tently following secure coding practices [73] Kanniah andMahrin found that a variety of organizational technical andhuman factors affected implementation of secure softwaredevelopment practices [38] These factors included developerskill and expertise communication among stakeholders andcollaboration between security experts and developers

Failures in development and testing leading to security errorsappear to reflect a deficiency in a security mindset Schneierclaimed that ldquoSecurity requires a particular mindset Secu-rity professionals ndash at least the good ones ndash see the worlddifferentlyrdquo [62] A security mindset involves being able tothink like an attacker maintaining a commitment to securepractices and perpetuating a strong security culture

A need for a security mindset is revealed in several studiesthat explored reasons why developers make security errorsFor example Xie Lipford and Chu identified an absence ofpersonal responsibility for security as well as a gap betweendevelopersrsquo understanding of security and how to implementit [76] Xiao et al discovered that the failure to adopt se-cure development tools was heavily dependent on social envi-ronments and how tool information was communicated [75]From a testing perspective Potter and McGraw argued thatsecurity testing is commonly misunderstood and should bemore risk-based involving an understanding of a potentialattackerrsquos mentality [58] Bonver and Cohen agreed notingthat security testers should work closely with architects anddevelopers to identify potential vulnerabilities taking intoaccount how an attacker may exploit a system [9]

3 METHODOLOGYBetween January and June 2017 we conducted 21 interviewsof individuals working in organizations that develop prod-ucts that use cryptography Following rigorous commonlyaccepted qualitative research methods we continued inter-viewing until we reached theoretical saturation the point atwhich no new themes or ideas emerged from the data [45]exceeding the minimum of 12 interviews prescribed in qual-itative research best practices [29]

Our research team was multidisciplinary and consisted of a

computer scientist specializing in information security andhuman-computer interaction a computer scientist specializ-ing in usability a mathematician with research experience inusable security and privacy and a sociologist experienced inqualitative research Having a diverse team may improve re-search quality ldquoin terms of enabling sounder methodologicaldesign increasing rigor and encouraging richer conceptualanalysis and interpretationrdquo [6]

The study was approved by our institutional review boardPrior to the interviews participants were informed of thepurpose of the study and how their data would be used andprotected Interview data were collected and recorded with-out personal identifiers and not linked back to the partici-pants or organizations Interviews were assigned an identi-fier (eg C08) used for all associated data in the study

31 RecruitmentTo ensure that we could explore different perspectives withinthe cryptographic product space our sampling frame con-sisted of individuals who had organizational experience de-signing developing or testing products that use cryptogra-phy or who were knowledgeable about and had played a keyrole in these activities (eg managers of teams that per-formed these tasks) We utilized a combination of purposefuland convenience sampling strategies which are widely em-ployed in exploratory qualitative research [56] Purposefulsampling was used to select organizations of different sizesand participants who had knowledge and experience withinthis specialized topic area This was combined with conve-nience sampling where participants were sought based onease of accessibility to the researchers and their willingnessto participate in the study

Nine individuals were recruited from prior researcher con-tacts Additional participants were recruited from amongvendors at the RSA conference [14] a large industry IT se-curity conference that also hosts an exhibition floor withsecurity-focused vendors A list of 54 potential organiza-tions was compiled after in-person researcher contact on theexhibition floor After the conference we identified organi-zations that provided organizational diversity in our sampleand that were accessible to the researchers We emailed 17of them to invite participation in the study Eleven organi-zations agreed to participate One additional organizationwas recruited based on the recommendation of a participant

32 InterviewsWe collected data via semi-structured interviews Interviewswere conducted by two of the researchers and ranged from30 to 64 minutes lasting on average 44 minutes We con-ducted 21 interviews with 1-3 participants per interview 29participants total Five organizations opted to have morethan one participant in the interview three organizationshad three participants and two organizations had two par-ticipants Face-to-face interviews were conducted if feasibleOtherwise participants were given the choice of a phone orvideo conference interview Five interviews were conductedface-to-face 10 by phone and six via video Interviews wereaudio recorded and transcribed by a third-party transcrip-tion service

After the first nine interviews we performed a preliminaryanalysis and chose to make minor revisions to the interview


protocol in accordance with the qualitative research prac-tice of theoretical sampling Theoretical sampling involvesadjusting data collection while the study is in-progress tobetter explore themes as they arise [13]

The interviews began with demographic questions aboutthe organization (eg size products) and the individualparticipants (eg role within the organization professionalbackground) Subsequently participants were asked to de-scribe their organizationsrsquo development and testing practicesand associated challenges for their cryptographic productsQuestions then transitioned into exploring cryptographic re-sources used by the organizations and how the participantsthought those resources might be improved if at all Thecomplete interview protocol is included in Appendix A

33 AnalysisWe utilized both deductive and inductive coding practicesInitially we constructed an a priori code list based on ourresearch questions and literature in the field to provide di-rection in the analysis As we performed multiple roundsof coding we also identified emergent codes in the dataThis iterative recursive process helped us identify additionalcodes and categories as we worked with the data until wereached saturation [2669]

Five interviews (almost 24) were first coded individuallythen discussed as a group to develop a codebook Althoughthere is debate on the amount of text to collectively samplein qualitative research the amount of text we group codedfar exceeds the minimum of 10 often cited as standardpractice [33] We calculated intercoder reliability on thissubset of the data using the ReCal3 software as a tool tohelp us refine our codes [21 22] For the five interviews wereached an average Krippendorfrsquos Alpha score of 70 witha high of 78 which is considered within the fair to goodbounds for exploratory research having rich data with manycodes and a larger number of coders [111539]

Beyond the agreement metric and in line with the views ofmany qualitative research methodologists we thought it wasimportant to focus on how and why disagreements in codingarose and the insights gained from discussions about these[5 63] These discussions better allow researchers to refinecoding frames and pursue alternative interpretations of thedata During analysis we found that each coder broughta unique perspective that contributed to a more completepicture of the data For example two of our coders moreoften identified high-level nuanced codes about emotionsand personal values which may be due to their many years ofworking in human-focused contexts These interpretationswere often missed by the other coders who had more of atechnology-focused background

After coding of the initial subset of data the remaining 16interviews were coded by two coders each Once each paircompleted their coding they had a discussion about the datato address areas of divergence about their use and applica-tion of the codes This discussion resulted in the coders be-ing able to understand each otherrsquos perspectives and come toa final coding determination New codes that were identifiedduring these discussions were added to the codebook withpreviously coded interviews then re-examined to account foradditions The final codebook is included in Appendix B

During the coding phase we also engaged in writing analyticmemos to capture thoughts about emerging themes [13]For example one memo captured thoughts on cryptogra-phy complexity Once coding was complete we reorganizedand reassembled the data created coding arrays discussedpatterns and categories drew models discussed relation-ships in codes and data and began to move from codes tothemes [59] The team met regularly to discuss our emer-gent ideas and refine our interpretations This process al-lowed for the abstraction of ideas and the development ofoverarching themes such as how an organizationrsquos maturityand security culture drive formal development practices

34 LimitationsOur study has several limitations First interviews are sub-ject to self-report bias in which participants tend to under-report behaviors they think may be viewed as less desirableby the researchers and over-report behaviors deemed to bedesirable [16] Given that the researchers who conductedthe interviews represented an institution known for its se-curity expertise this bias may have influenced participantresponses We also note that the answers to some of theinterview questions reflected participantsrsquo perceptions of thesecurity level of their products and the security mindset oftheir organizations which may or may not reflect reality

Since there is no prior research into what is representativeof the cryptographic development community our sample isnot characteristic of all types of organizations in this spaceAlthough we did strive for diversity in organization size witha smaller sample size common in qualitative research wecannot definitively identify differences due to this variable

4 DEMOGRAPHICSTable 1 provides an overview of the organizations and par-ticipants in our study To protect confidentiality producttypes and participant roles are generalized

The organizations represented in our study were of differentsizes with six being very large (10000 or more employees)six large (1000 - 9999 employees) three medium (100 -999 employees) three small (10 - 99 employees) and threevery smallmicro (1 - 9 employees) [24 32] All organiza-tions developed a security product that uses cryptography(eg end user security software hardware security module)or a non-security product that heavily relies upon cryptogra-phy to protect it (eg Internet of Things devices storagedevices operating systems) Customers of these productsranged widely and included consumers other parts of theorganization and organizations and businesses in multiplesectors such as government technology health finance au-tomotive and retail Of the 15 organizations that discussedhow long their companies had been implementing cryptogra-phy in their products 12 had 10 or more years experiencewith six of those having at least 20 years experience The re-maining three were startup companies that had been doingcryptographic development since their inception

The 29 participants were a highly experienced group withseveral having made major contributions to the cryptogra-phy field All participants had technical careers spanning10 or more years with several having been in the field for30+ years At least one individual from each of the inter-views either currently worked on cryptography and securityas a major component of their jobs (19 participants) or had


Table 1 Interview DemographicsOrg Prod

ID Size Reg Type Participant(s)C01 VL US HW Lead crypto architectC02 VL US COM Lead cryptographerC03 VL US HW SW Systems architectC04 VL US HW Crypto design reviewerC05 VL US HW Crypto architectC06 VS US SW Systems analystC07 VS US COM Founder amp researcherC08 VS US IOT Founder amp developerC09 VL US IOT ResearcherC10 L US SW Founder amp engineering

leadC11 L US HW SW Product managerC12 S US SW 1) CTO

2) Marketing engineer3) Business manager

C13 S US SW 1) Chief Evangelist2) Strategy Officer

C14 M US SW 1) Marketing lead2) Developer3) Quality assurance

C15 L US SW Principal engineerC16 L US SW CISOC17 M Eur SW 1) CTO

2) Security engineerC18 L Aus SW Crypto engineerC19 L US SW CTOC20 S US COM 1) Founder amp architect

2) Compliance lead3) Marketing director

C21 M Eur SW Crypto specialist

Org Size VL=Very Large M=Medium S=SmallVS=Very SmallMicro Reg (Regionlocation of partici-pant) US=United States Eur=Europe Aus=AustraliaProd (Product) Type HW=Hardware SW=SoftwareCOM=Communications Security IOT=Internet of Things

worked on cryptography extensively in the past (3 partici-pants) The other participants were marketing or productleads but all had a technical background

Most of the participants had learned cryptography ldquoon-the-jobrdquo as opposed to having formal training in the field Fivehad an education in mathematics but only two of those hadstudied cryptography as part of their formal study Threehad an engineering education one had a physics degree andthe rest were educated in a computer-related discipline

Four out of the 29 total interview participants had enhancedtheir knowledge through involvement in cryptographic stan-dards groups A cryptography architect commented on thevalue of his involvement in IEEE cryptographic standardsearly in his career ldquoThatrsquos where I got to commune withcryptographers for a couple of years me on the engineeringside and them on the crypto side You end up learningthings as a result of that processrdquo (C05)

5 RESULTSThe interviews revealed an organizational security mind-set seldom seen in other cryptographic development stud-

ies Our results suggest that the security mindsets had theirroots in organizational attributes and culture that lay thefoundation for the selection and use of cryptographic re-sources and rigorous development and testing practices

For this section we report counts of interviews throughoutjoining group interview participantsrsquo answers to account fortheir organization Due to the semi-structured nature of theinterviews the counts do not indicate quantitative resultsbut are reported to give weight to certain themes that werementioned across interviews

51 Security Mindset CharacteristicsThe interviews revealed organizational and personal charac-teristics that demonstrated a strong security mindset Thesecharacteristics included professional maturity gained throughexperience a deep understanding of the complexity of cryp-tography and evidence of a strong security culture

511 Emphasis on Experience and MaturityBruce Schneier said ldquoOnly experience and the intuitionborn of experience can help the cryptographer design se-cure systems and find flaws in existing systemsrdquo [61] Thestudy participants expressed the importance of this expe-rience as they repeatedly highlighted their own and theirorganizationsrsquo substantial maturity with respect to develop-ing secure products and working with cryptography

Overall the organizations placed great value on hiring andretaining experienced technical staff As previously men-tioned the majority of participants had substantial indi-vidual experience with cryptographic products They alsotended to work with other seasoned individuals One par-ticipant described his team ldquoWe have a couple of the samecore people on our test team whorsquove been here for 25 yearsTheyrsquove gotten very goodrdquo (C01) A startup company hadonly a few employees but they all were veteran security soft-ware developers ldquoEveryone we have has a lot of experienceI think the most junior person has a masterrsquos degree and10 and a half 11 years of experiencerdquo (C07)

Eight interviews noted the importance of experience whendoing secure development especially with cryptography Oneparticipant remarked that secure products are ultimately de-pendent onldquothe people that are designing it having the neces-sary knowledge and experience and understanding the wholepicture not just the little microscopic piece theyrsquore workingonrdquo (C01) An interviewee with a long cryptographic back-ground emphasized that there is no substitute for experienceas he recounted a story of how his former company had tohire three less-qualified full-time people to replace him inthe work he had been doing on a part-time basis A companyfounder remarked about the high level of technical maturityneeded to properly deal with the complexity of cryptogra-phy ldquoThe level of education somebody needs to attain to beeffective at doing crypto is relatively high So itrsquos not likeI can put somebody whorsquos fresh out of school on somethingand expect good resultsrdquo (C10)

512 Recognition of Cryptography ComplexityBased on their own experiences participants and their or-ganizations were keenly aware that even though develop-ing secure cryptographic implementations may appear tobe easy it is deceptively difficult Despite proven algo-rithms being available ldquothe algorithms are fairly involved


and theyrsquore difficult to understandrdquo (C20) Yet understand-ing the algorithm is just the first step As described by anIoT researcher translating the algorithm correctly into aproduct is ldquonot a trivial implementationrdquo (C09) One designreviewer remarked about the pervasiveness of cryptographicdesign errors he encountered over the course of his career ldquoIthink I reviewed about 2500 products I can only remembereight that did not have a problem that either they had tofix or they had to change their marketing claimsrdquo (C04)

Our interviews also suggest that building cryptographic sys-tems appears to be more of an art than a science requiring acareful balance between security performance and usabilityOne participant described these tensions

ldquoCrypto algorithms are already very highly optimized Itrsquos like balancing a supertanker on a 40000-foothigh razor blade and if you make one small changeyou destroy the performance If you make it the otherway you just destroy the securityrdquo (C04)

Because of the complexity our participants recognized thatdesign and implementation errors can be rampant and re-quire rigorous review and testing to answer the misleadinglysimple question ldquoHow do you know itrsquos rightrdquo (C08) How-ever assessing cryptographic products can be challengingrequiring knowledge and experience to construct good testsA cryptographic development architect described challengeshis organization had in the past when they lacked maturityin cryptographic implementation and testing

ldquoWe actually implemented a new symmetric encryptionalgorithm and it passed all the tests and it turnedout that they did the algorithm completely wrong Thatwas because they wrote a test which said lsquoGener-ate some random data encrypt it with the algorithmdecrypt it and see if you get back the original datarsquoWell yeah it got back the original data but the en-crypted data was incorrect It just was symmetric soit did the same wrong thing encrypting and decrypt-ingrdquo (C01)

The organizations also understood that cryptography is justone of many interdependent product components with allof them having to be properly implemented to ensure se-curity This sentiment was echoed by one participant whocommented ldquoFor us the design of the overall architecturethat uses the crypto algorithms is almost as important as thecorrectness of the underlying algorithms themselvesrdquo (C01)

513 Security CultureEach organization in our study appeared to have a strong se-curity culture that was interdependent on the maturity andexperience of its employees A security culture is a subcul-ture of an organization in which security becomes a naturalaspect in the daily activities of every employee [60] For de-velopment organizations this involves having dedicated se-curity people spending money on security making securitya company core value and offering secure products For thestudied organizations the culture included a commitment toaddress security and the perpetuation of a security mindsetto others in the organization

Commitment to Security The organizations we studiedthought that having good product security and strong cryp-tographic implementations was a ldquocore valuerdquo (C07) ldquothe

key to qualityrdquo (C09) and essential to company identity Asan example a Chief Information Security Officer (CISO) of alarge company remarked ldquoIn our company we are develop-ing and selling security to our customers So we care aboutbasically all three sides of the sort of security triangle [con-fidentiality integrity availability] in what we dordquo (C15) Asecurity engineer talked about his companyrsquos belief that se-curity must be an important consideration even when facedwith competing tensions such as time-to-market ldquoSince wedo a [security product] everybody feels that we need to addsecurity and good crypto at every step so itrsquos not a big issueto find the right balancerdquo (C17) Another participant com-mented on how his company demonstrates its commitmentto secure cryptography ldquoWe have some fairly large teamswhich concern themselves with cryptography and secure de-sign methodology All engineers get training on secure designand we make it a big deal in the companyrdquo (C05)

Security culture is not just internally-motivated Externalmotivators like gaining a larger market share or customerrequirements often necessitate strong attention to securityOne participant commented on how customer expectationsfostered a security culture that drove rigorous testing pro-cesses within his company

ldquoWe serve the kinds of customers who rely on the stuffto work reliably and properly from the get-go when theybuy it So itrsquos not like lsquoMaybe wersquoll update some-thing later if we find some problemsrsquo Thatrsquos not ourphilosophy and thatrsquos not what our kind of customersexpect Part of that is also company culturerdquo (C01)

Although security culture is often thought of as aldquotop-downrdquophenomenon it must be accepted by and acted upon atall levels One participant a CISO for a large companycommented on the importance of the security culture beingpervasive throughout an organization

ldquoIf therersquos senior executive support for a strong securityprogram that helps tremendously At the same timeif there is still a very strong feeling amongst a largenumber of developers that security cryptography andeverything thatrsquos related to that is really a nuisancethat should get out of the way and just to prevent themfrom writing more interesting features itrsquos definitely aconcernrdquo (C16)

The interviews showed evidence that our participants arecritical to the ldquobottom-uprdquo support of organizational secu-rity culture They serve as security champions and self-appointed educators leading by example and projecting theirvalues personal philosophies and commitment to securityon the rest of the organization Two of the participants ex-plicitly embraced this role as a personal mission when theyreferred to themselves as ldquosecurity evangelistsrdquo Another ex-pressed his feeling of personal accountability to enact secu-rity in the products he supported ldquoItrsquos essentially a markof my success or not that Irsquom measured against of whetherthose things remain secure or hackedrdquo (C05)

Perpetuating a Security Mindset Just as the employ-ees influence security culture so does the culture influenceemployees by perpetuating a security mindset Part of thisperpetuation involves expert employees mentoring and sup-porting less-experienced personnel in their learning of secureprogramming methods and specialized security topics such


as cryptography as discussed in ten interviews

The interviews suggest that providing an opportunity forindividuals to gain hands-on experience with real productsis important in understanding the issues involved in devel-oping a cryptographic product However given the distinctpossibility that a novice will make errors in the implemen-tation precautions must be taken Two participants sug-gested that mock training exercises conducted on a separatetesting infrastructure may be valuable initial steps Oth-ers discussed mentoring and peer review activities withintheir organizations For example one organization enactedldquoparent programmingrdquo (C14) for any code that uses crypto-graphy Another had a formal peer review process

ldquoWe review everyonersquos code When I write somethingdown and it has a flaw in it Irsquom told about it which isgood I think what we do is we take smart people whocare about doing good work and we foster an environ-ment where theyrsquore not afraid to receive constructivecriticism and theyrsquore not intimidated away from giv-ing itrdquo (C15)

The influence of an organizationrsquos security mindset does notnecessarily end when an individual leaves that organizationAs evidenced by three participants who left large compa-nies to start their own small businesses there seemed to bea transfer of security culture and practices from previousemployers A small company founder described this trans-fer ldquoI think some of it could be just kind of from my careerbackground what I learned were the best practices I thinkwersquove just kind of learned them in the beginning and kind ofkept that culturerdquo (C08)

Size Doesnrsquot Matter We found no significant differencesin perceived security culture or overall security practicesbased on size Obviously larger organizations had moreresources to dedicate to security and cryptographic devel-opment However smaller organizations understood thatvulnerabilities in their products could do great harm to thecompanyrsquos reputation and so were committed to securityand made thoughtful decisions about how they developedand tested even if on a smaller scale For example thefounder of a micro business noted

ldquoBeing a small company wersquore trying to also gain cred-ibility And we donrsquot want to just claim that we havethe fastest [crypto implementation] in the world wealso want to make sure that it is built safely and vali-dated [W]e cannot afford for this thing not to workproperlyrdquo (C07)

52 Selection of ResourcesBecause of security mindsets participants revealed a pro-clivity towards careful selection of resources to help themattain their goal of secure cryptographic implementationsIn this section we describe considerations taken when choos-ing and evaluating cryptographic resources

521 StandardsIn line with the popular quote ldquoThe nice thing about stan-dards is that you have so many to choose fromrdquo by An-drew S Tanenbaum [67] the interviews revealed that allthe organizations used some type of cryptographic standardsfrom organizations such as IEEE ISO American National

Standards Institute (ANSI) [3] Internet Engineering TaskForce (IETF) [37] and Payment Card Industry (PCI) [57]All but one described using NIST standards or guidancedocuments most commonly FIPS 140-2 The participantsand their organizations were knowledgeable enough to un-derstand and evaluate the appropriateness of cryptographicstandards However not all organizations have the needto directly read the standards For those that do this re-quires maturity in the field given the standardsrsquo complexityA Chief Technology Officer (CTO) at a small company ex-pressed this challenge ldquoA lot of standards are notoriouslydifficult to read Unless yoursquore an expert in the field a lotof them donrsquot make senserdquo (C12) In another interview aprincipal engineer commented on the difficulty in translatingstandards to products

ldquoI can tell you from my personal experience under-standing the fundamentals of these things still the stan-dards were a challenge to use because they were very di-vorced from the implementation day-to-day details thatI encounter while Irsquom trying to plug all the pieces to-getherrdquo (C15)

Despite the complexity when selected carefully and imple-mented correctly standards were seen as beneficial for sev-eral reasons noted by our participants Participants in eightout of 21 interviews commented that the community reviewof standards results in a more correct and secure solution ACISO at a large software as a service company reflected onthe value of public scrutiny ldquoBy relying on other standardsthat [were] vetted by multiple parties I have much higherassurance that the underlying cryptography and design [are]done in an appropriate wayrdquo (C16) A director of productmanagement concurred with this ldquoSo the standards becauseitrsquos out there and everybodyrsquos looking at it and testing it wedepend on that as kind of a layer of securityrdquo (C14)

Included in community review is the transparency of thestandards process One participant illustrated this observa-tion using the popular AES standard as an example

ldquoIt gave us a lot of comfort knowing how AES evolved being able to see all the steps having that all happenout in the open and why and how it happened Veryhelpful to us making the decision for what wersquore goingto use and why wersquore going to use itrdquo (C10)

Participants in nine out of 21 interviews commented that theuse of standards eliminates some of the difficulty of crypto-graphic development and testing by providing an authorita-tive foundation The founder of a software company said hisorganization relies heavily on standards because ldquoinventingit on your own is just a different level of complexity thatwe knew enough to know we did not want to be involvedinrdquo (C10) Standards also add confidence that a productwill be ldquointeroperable with our customers with our partnerseven with our competitorsrdquo (C16)

Finally participants noted that standards-based productsmay elicit customer confidence The director of productline management at a large credential management com-pany spoke of the importance of customer trust in gain-ing market share saying ldquoIf the standard is mature thenit means our productrsquos going to be more easily accepted bycustomersrdquo (C11)


Standards meet the needs of most companies we interviewedhowever there are cases in which standards fail to addressa specific need In these situations organizations may ex-tend or modify standards These extensions were viewed asadding rigor and security in addition to functionality mak-ing the cryptographic implementations ldquoreally ahead of anyindustry standard practicesrdquo (C05)

Interestingly three participants commented on distrust ofgovernment standards because of allegations that a USgovernment agency purposely weakened cryptographic algo-rithms [28] For example although one organization madeextensive use of standards they took special measures to ex-clude aspects of a government standard they felt were ques-tionable and exercised extra rigor in their testing processesto account for potential vulnerabilities In an extreme casea consulting companyrsquos observation of customer distrust ofgovernment standards and their own frustration with thecomplexity of those led them to develop a new cryptographicprimitive ldquoI think it [the distrust] comes from news re-ports or exposes that say this standard may not be as secureas we think There is a lot of doubt out there Thatrsquos whythere has to be additional options and alternativesrdquo (C06)

522 CertificationsSeventeen out of 21 organizations obtained at least one for-mal certification that the implementation of cryptographicalgorithms in their products met standards specificationsThree additional organizations developed and tested to cer-tification criteria without undergoing full certification Eigh-teen organizations referenced FIPS 140-2 certification [49]five Common Criteria [41] three the Payment Card IndustryData Security Standard (PCI-DSS) [57] validation programone the Underwriters Laboratories (UL) certification [70]and others pursued country-specific certifications

The perception of the benefit provided by adhering to cer-tification requirements was mixed among our participantsAmong those who obtain certifications only five organiza-tions expressed that certifications establish additional confi-dence through independent testing One of these remarkedldquoYou have a lot of assurance that everythingrsquos going to betested and get that nice kind of warm and fuzzyrdquo (C08) Sixorganizations noted that even though they do not undergothe formal FIPS 140-2 certification process they build toand test against the certification specifications to gain addedassurance A participant from a key and identity manage-ment software company stated ldquoas a small company I thinkit is actually extra important to make sure that we go throughthis battery of tests just to in a way reassure the people wersquoretalking to that this is a robust productrdquo (C12)

For some participants certifications are perceived as beingmore useful for meeting customer expectations than for bol-stering security Organizations most often obtain certifica-tions because these are requirements of their customers incertain sectors (eg government financial) ldquofor some areasif you donrsquot get the check-mark you donrsquot get to playrdquo (C11)

Unfortunately as noted in 12 of 21 interviews certificationscan be expensive in time and resources making them pro-hibitive for smaller companies especially those with prod-ucts that run on multiple platforms and have frequent ver-sion updates However our interviews suggest that con-fidence in the cryptographic implementations may not be

dependent on any certification but rather on the rigorousdevelopment and testing practices these organizations un-dertake The founder of a small company commented thatFIPS 140-2 certification was too costly for them to pursuebut was confident that his product met the certification re-quirements ldquoItrsquos a place where wersquove done enough testingourselves I know itrsquos fine I know we would passrdquo (C10)Another participant whose company did undergo certifica-tions felt that the certifications provided little assurancebeyond what was provided by their own internal processes

ldquoWe always design and test ourselves to have confi-dence that [the product] meets all those requirementsbefore we release it to the lab for their testing So whenthey come back and say lsquoIt passed thisrsquo we say lsquoWellokay we expected that Thank yoursquo So the surpriseis if something fails that we expected to pass Thatdoesnrsquot happen very oftenrdquo (C01)

Four of our participants also remarked that certificationsmay not be a robust contributor to the security of a productThey expressed strong sentiments that certifications espe-cially FIPS 140-2 are more of a ldquocheckboxrdquo for customersldquowithout any additional benefit of securityrdquo (C02) A CTOand long-time cryptographer added ldquoFIPS 140 is not fo-cused on how to use crypto securely Itrsquos focused on how tosafely provide crypto functionalityrdquo (C19)

In addition seven out of 21 organizations commented thatmaintaining FIPS certification may in some cases weakensecurity by discouraging updates throughout the lifecycle ofthe product Once a product undergoes a significant update(for example fixing a security vulnerability) it may loseits certification Organizations are then put in a difficultposition ldquothis ability to address vulnerabilities and to patchvalidated code is a real problem It sends the wrong messageif you do what you should do which is patch it and livewithout [the certification]rdquo (C19)

523 Third-Party ImplementationsThe complexity of implementing algorithms from scratchand the expertise required to write those compelled twothirds of the organizations to follow industry best practicesby not writing their own cryptographic code and instead us-ing third-party cryptographic implementations for exampleopen source libraries such as OpenSSL or built-in operatingsystem APIs One participant used an analogy to explainwhy his organization used these resources ldquoNot every per-son should be performing brain surgery on another personI also donrsquot believe every software engineer should really gowrite crypto coderdquo (C07)

The organizations selected these third-party implementa-tions based on several factors First four mentioned animplicit trust of the resource based on the reputation of thevendor or general community acceptance In describing whyhis organization chose a set of cryptographic libraries oneparticipant said ldquoYou pretty much trust those libraries be-cause they are widely used and you can run test vectorsagainst them easilyrdquo (C20) A third of the organizations saidthat they have more confidence in formally vetted certifiedimplementations A participant from a small company thatworks on IoT cryptography commented ldquoIf a vendor hassubmitted a library through FIPS 140-2 certification ver-sus a code that was up on GitHub for example I would


be more inclined to trust the one that has gone through theFIPS validationrdquo (C08)

Despite benefits of using third-party implementations theorganizations respected that the use of these external re-sources can still be difficult for less-knowledgeable individu-als A developer provided an example

ldquo[Crypto libraries] in general donrsquot provide enough to beable to use them correctly out of the box But therersquosmany out there that think that they can just use AESand I included it and Irsquom using it But Irsquom not us-ing it correctly and then Irsquom leaving myself open toattackrdquo (C14)

This point illustrates that there is an important distinctionbetween a cryptographic algorithm being certified or deemedldquosecurerdquo and the proper use of the algorithm by developersSimilarly third-party libraries have faced their share of se-curity vulnerabilities due to implementation errors of oth-erwise sound cryptographic algorithms Some of these vul-nerabilities have had far-reaching impacts for example theHeartbleed vulnerability in OpenSSL [71] A security archi-tect commented that third-party implementations areldquomuchmore likely to contain implementation bugs and vulnerabil-itiesrdquo (C20) Therefore some organizations attempted tovet third-party implementations by doing their own vulner-ability checks One participant noted that his organizationmonitors the vulnerability databases for security issues withthe libraries they use Another commented on the extra se-curity checks his company performs ldquoWe validate outsidethird-party libraries and software as they come in and con-firm that they are bug-free and up to the latest standard orperform the right risk assessmentsrdquo (C16)

Finally organizations may augment third-party implemen-tations with their own internally developed modifications toavoid potential errors or address gaps in the resources Forexample to prevent developers from making errors whileusing the Windows CryptoAPI a vulnerability assessmentsoftware company had ldquowritten libraries on top of that topresent a prettier facade in front of it because itrsquos a fairlydifficult library to use the way itrsquos deliveredrdquo (C15)

524 Academic and Research ResourcesOur interviews revealed differing views on the value of aca-demic research resources Participants in three out of 21 in-terviews said that they have referenced academic resources(eg attended academic conferences or read (attack) re-search papers) to either better understand cryptography orto keep up with advances in the field However other par-ticipants passionately voiced their lack of confidence in therelevance of cryptographic research to their organizationsrsquoreal-world industry challenges One participant commentedldquoPeople out in academia are famous for claiming there areholes in this kind of stuff where they donrsquot actually existbecause they donrsquot configure things according to the recom-mendationsrdquo (C01) A cryptography architect asserted thathis companyrsquos testing methods for cryptographic implemen-tations were more state-of-the-art than those described inthe academic world ldquoNo we donrsquot reference academic pa-pers Theyrsquore not where we are in understanding the testproblem So therersquos a six-year gap between the methodsthat we developed being identified in academiardquo (C05)

53 Development and Testing RigorOur interviews revealed that the organizations translatedtheir commitment to security and their expertise into rigor-ous development and testing practices Interestingly whenparticipants spoke about how they test the cryptographiccomponents they saw secure software development as thefoundation to providing cryptographic functionality

531 Formal ProcessesOf our 21 interviews 20 reported that their companies em-ployed formal development and testing strategies (those thatare structured and standardized within the company) to en-sure that their products including the cryptographic com-ponents were secure while one participant said that theycontracted developers to do that for them

The development and testing practices were often the resultof an evolutionary process spanning many years as notedby 10 interviews A director of quality assurance remarkedldquoPart of [the role of] our test lead is now to verify that wersquoreat the appropriate levels from a security standpoint so itrsquosa big focus for us now whereas in the past it was kind of aside itemrdquo (C14) A company founder described his organi-zationrsquos introduction of more robust techniques over time

ldquoAnd it was an evolution honestly It started to wherewe didnrsquot have hardly anything and new tools came onthe market as well as we had more time to focus on itThat allowed us to kind of improve code incrementallyover timerdquo (C10)

Twelve interviews revealed a strong security mindset whenthey described developing and testing their productsrsquo cryp-tographic components based on risk They would carefullybuild threat models to protect against strong adversariesperform penetration testing and would monitor current vul-nerabilities to ensure their products were secure against thoseA cryptographic design reviewer commented on this risk-based approach ldquoAll we can do is try to build good adver-sary models and then try to determine if our systems canstand up to those adversariesrdquo (C04)

Another discussed how his companyrsquos practices ensured thatsecurity had been considered throughout development

ldquoWe have architects that do security reviews that dothreat modeling And itrsquos not just about the crypto butmore in general how do you use the product Who getsto do what What are the risks How do we mitigatethose risks And one of the items for the engineer-ing gate release is making sure we mitigated anythingthat needed to be mitigatedrdquo (C11)

Generally the organizationsrsquo development and testing pro-cesses adhered to the principles in Figure 1 First securityspecifications architectures and designs would be developedand reviewed These would then be programmed againstInternal or external code reviews would be subsequently beconducted During testing tests would be run using inter-nally developed test vectors or those provided with cryp-tographic resources Static analysis tools and testing toolswere also generally used This development and testing pro-cess would be iterated whenever functionality changed andperformed in an expedited fashion if updates were beingmade due to a discovered security vulnerability


Functional TestingUnit tests

Code reviewsInteroperability tests

Stability testsPerformance tests

informs

whiteboxgreyboxblackbox

Security TestingUnit tests

Code reviewsStatic code analysis

FuzzingDynamic analysis

(external) code audits

release post release

Pentesting

SystemLeveltests

Certi-fication

Continuous testingVulnerability database monitoring

Specifications RequirementsResourcesExperienceTest plan

Threat modelingCustomersStandards

Secure defaults

Security testing of 3rd

party resources

bug hunting

next iteration

refine Reqsclear Specs

development

testing

Figure 1 Security Development Lifecycle [34] adapted to include development and testing strategies asextracted from the interviews Not all processes apply to all interviewed organizations

532 DevelopmentAs mentioned above the development phase for the orga-nizations followed typical commonly accepted developmentpractices such as requirements and risk analysis and pro-gramming We specifically highlight two practices that werementioned most often in the interviews

Participants in nine interviews spoke about design reviewswhich were critical for finding potential errors in crypto-graphic components early in the process Those that docryptographic review must be highly skilled and able to piecetogether othersrsquo thought processes

ldquoA lot of the review is really just archeology Itrsquos delv-ing down into what theyrsquore producing trying to under-stand both the explicit and the implicit assumptionsand then identifying where there are conflicts that leadto attacksrdquo (C04)

Nine organizations also mentioned the importance of doingcode reviews to look for security and functional errors andvulnerabilities A participant from a security software com-pany remarked ldquoWe have a mandatory and systematic codereview Each line of code and each comment of code needsto be reviewed by usually at least two peersrdquo (C17)

533 TestingFigure 2 shows the types of testing mentioned in the inter-views In 16 interviews automated testing was discussedoften as being integrated with manual testing The CTOof a company that produces security software discussed thisintegration of automated and manual testing ldquoWe have au-tomatic tests unit tests integration tests functional tests code analysis We have additional manual tests be-ing done on top of the automated testsrdquo (C17)

design reviews

code reviews

automated

external3rd party

withby end users 8

10

16

9

9

Figure 2 Development and testing practices explic-itly mentioned for secure cryptography

Ten interviews mentioned the use of third-party testing toimprove the security of their cryptographic products Forexample organizations used bug-hunting services or exter-nal testing such as blackbox greybox or whitebox penetra-tion tests to increase the chances that bugs would be foundin a controlled environment and prior to product releaseOne participant described the benefit of his company usinga bug-finding platform

ldquoYou have some complete geniuses there that have foundthings that we never would have found I feel likeyoursquore way more trustworthy if you are actually upfrontabout this stuff and you are actively soliciting people toattack you and paying them for their effort You get amuch higher confidence that some random person at-tacking wonrsquot just find something easyrdquo (C10)

Third-party review can also be used to gain trust with cus-tomers as expressed by a product manager ldquoWhen cus-tomers ask us lsquoCan you prove to me that itrsquos done se-curelyrsquo we can point to another organization thatrsquos inde-pendent to showrdquo (C11)


updates were challenging

time to market vs security

vulnerability testing

longevity of products

test vectors needed

keeping up with standards

multiple platforms 3

3

3

3

7

6

19

Figure 3 Challenges in development and testing

End-user testing was not deemed as important for some or-ganizations as they mostly develop products that becomecomponents in other products However this type of test-ing is critical for those producing products that will be di-rectly used by businesses and consumers and was discussedin eight interviews These interviews mentioned formal beta-testing continuous feedback employing a user testing ser-vice or recruiting convenience samples to test the productOne participant described the importance of user testing forhis organizationrsquos consumer security software

ldquoWersquod bring in our friends and family and sit themdown and watch them And it was eye-opening Itcaused us to change a lot of what we did because es-sentially they didnrsquot get the concept We also usedusertestingcom which has been very great You canshow 10 people something and you have a pretty goodideardquo (C10)

Another company takes advantage of beta testing to identifypotential issues in their product ldquoWe have a very extensivebeta program and we have a very active customer base sowe have no lack of feedbackrdquo (C15)

534 ChallengesAll 21 of our interviews mentioned challenges to develop-ment and testing (Figure 3) We focus here on challengesdirectly related to cryptography excluding challenges thathave already been discussed eg cryptographic complexity

One challenge mentioned in six interviews was the tensionbetween getting a product to market and taking the time todo robust security development and testing For example aparticipant from a company that spends years securely de-veloping its cryptographic hardware modules observed thatin most of the hardwaresoftware industry ldquoThe design fo-cus is simply not to do a solid job which will last a long timecryptographically They cannot care because they have toget the products out in a timely fashionrdquo (C05)

Testing for vulnerabilities in cryptographic implementationswas another challenge mentioned in seven interviews withthree expressing concern for adequate testing of side-channelattacks A participant who integrates cryptography into IoTdevices said ldquoespecially in the embedded world what the testvectors donrsquot address I think is side-channel attacks [which]could be really detrimental to the embedded devicerdquo (C08)

Another challenge as mentioned in three interviews wasthe longevity of cryptographic products in customer spaces

An IoT researcher commented ldquoMany devices are going tobe deployed for 20 years So maybe the crypto in 20 yearsis no longer securerdquo (C09) Another participant expressedthe difficulty of having to maintain legacy cryptographic al-gorithms in a product ldquoOld things become weak and youshouldnrsquot use them anymore and you need to add new ones However customers are not so cooperative It may take10 years before everybody stops using somethingrdquo (C01)

Four interviews discussed challenges in having to troubleshootor update third-party cryptographic implementations whenvulnerabilities or errors are found A principal engineer at asecurity software company described ldquowhen wersquore using anythird-party libraryand you happen to do something and itfails itrsquos really hard to figure out what went wrongrdquo (C15)

Other cryptography-related challenges included the need formore test vectors (3 interviews) keeping up with changesin cryptographic standards (3) and having to use crypto-graphic libraries on multiple platforms (3)

In spite of these challenges organizations in our study re-ported confidence in their processes and the resulting se-curity of their cryptographic products (16 interviews) Forexample a senior systems analyst at a small company de-scribed his confidence in the cryptographic algorithm theyhad developed ldquoI donrsquot make any bold claims but at thesame time we looked at our encryption algorithm and weconsidered it quantum-proofrdquo (C06) In another interviewa company founder stated ldquoI think we are definitely in thehigher echelon for going above and beyondrdquo (C10)

6 IMPLICATIONS

61 Expanding Research ContextsOur results suggested that the organizations believe theyhave a mature workforce appreciate the complexity of cryptopossess a strong security culture effectively use cryptographicresources and practice secure development However thevarious studies mentioned in Related Work (eg [1 2 17ndash194248]) indicate that there are many poor cryptographicimplementations ldquoin the wildrdquo and developers typically lacka fundamental understanding of cryptography

Where then is the disconnect between our findings and pastresearch It is possible that our self-report data are merelyperceptions and do not accurately reflect the security mind-sets of the organizations Participants may be overconfidentor may have overstated their organizationsrsquo security prac-tices because of observer bias We also recognize the value offuture research to verify organizational claims by examiningvulnerability databases for example Common Vulnerabili-ties and Exposures (CVE) [68] to enumerate security issuesin their products Additionally knowledge of an organiza-tionrsquos development maturity level (eg Capability MaturityModel [12]) could be used as a comparison point

Alternatively this population is likely quite distinctive frompreviously studied developer populations and contexts whichmay explain some of the differences in our findings Firstour participants exhibited more maturity in security andcryptography with all having more than 10 years of secu-rity development experience Second organizational cultureand constructs were an important driver of security mind-sets within our study while previous studies often involved


independent application developers many of whom were notfull-time developers or had not received formal education ororganizational training in programming cryptography or se-curity Third there was a marked difference in the types ofcryptographic resources used Other studies (eg [2]) in-dicated that developers are reliant on information gleanedfrom search engines and Stack Overflow which was onlymentioned once in our interviews Instead the organiza-tions in our study turned to more authoritative resourcessuch as cryptographic standards and certification specifica-tions Finally many of the studies that identified crypto-graphic vulnerabilities examined mobile apps presumablybecause these were easy to obtain from public applicationstores and open source projects Our participants were de-veloping more complex expensive software and hardwareproducts Lack of security in these products had greaterconsequences with the potential of harming the companyrsquosreputation or resulting in loss of sales

These differences suggest that perhaps the security researchcommunity is not capturing a comprehensive picture of thecryptographic development environment This demonstratesthe need for the research community to diversify their studypopulations and contexts and consider mechanisms to bridgethe gap between more security-mature and less-skilled devel-opers who implement cryptography in their products

62 Support for Other PopulationsThe evidence of the criticality of organizational security cul-ture and collaboration during development and testing raisesthe question of whether it is even possible for ldquosolordquo devel-opers such as the application developers with little crypto-graphy experience or peer support represented in previousstudies to be truly successful in this area How then can theresearch community explore ways to facilitate the transferof strong security practices observed in some organizationsto others with less support and experience

As previously stated unlike the population in our studymany developers sampled in past studies rely on online com-munities such as Stack Overflow [65] when implementingcryptography But there is little evidence that these com-munities provide the level of support necessary for securedevelopment Future research may involve further assessingthe value of current online communities for cryptographicdevelopment and exploring alternatives as means by whichsecurity mindsets can be created and perpetuated

The findings also reveal that mentoring and peer review arecritical to perpetuating security mindsets within organiza-tions Past studies have sought to understand the effective-ness of software development mentoring peer review andpair programming (eg [7 47 74]) However more workneeds to be done to determine whether mentoring for cryp-tographic development requires different tactics and how tobest support this outside of organizational constructs

63 Cryptographic Resource UsabilityWhereas the bulk of responsibility in producing secure cryp-tographic products lies with the organizations themselvesour results imply that cryptographic resource providers canalso do more to contribute to developer confidence Themost mentioned complaint our participants had with stan-dards and certification guidance was the complexity of thelanguage This underlies a need for standards organizations

to work towards a common language between cryptogra-phy experts who write the standards and developers andengineers who use them Although standards documentsmay not be the appropriate place for large amounts of ex-planatory text supplementary guidance that contains moreinstruction cautions against common errors and providesexample implementations may prove to be valuable Justas research has been done on language for security alertsand warnings (eg [10 66]) it would also be helpful for re-searchers to explore the efficacy of language that explainscryptography concepts to non-experts

Additionally developers could benefit from more explana-tions of motivation in other words the ldquowhyrdquo behind cryp-tographic choices One participant echoed this recommen-dation as an important way to move beyond the ldquocheckboxrdquomentality of standards ldquoSo yoursquore thinking big picture lsquoIrsquomdoing this for this a reasonrsquo because otherwise you just getin the cookbook approach of lsquoDo I meet this Yes yes yesCheck check checkrsquo rdquo (C19)

Of course many developers have no need to look at the stan-dards directly since they use third-party implementationsHowever third-party implementations may also be difficultto interpret and use securely if one lacks basic knowledge ofcryptography Our study results support past research call-ing for increased usability of cryptographic APIs Similar tothe work of Montandon et al that proposed a new platformfor providing API code examples [46] we also recommendinvestigating new approaches to community vetting of sam-ple code since developers often copy flawed code snippetsfrom forums such as Stack Overflow [2]

Notably the participants spoke of a security problem withFIPS 140-2 updating certified software for security wouldbreak its certification so companies relying on the certifica-tion had to decide between withholding an update or hav-ing to undergo recertification This insight into an instancewhere reliance on a certification can decrease security un-derlines the need to closely and continuously involve crypto-graphic experts in the certification process Their experienceas users of the certification can help evolve the process andshape it to be more resilient usable and secure

7 CONCLUSIONOur study offers new insight into the cryptographic develop-ment and testing practices of a previously unstudied popula-tion of organizations and participants who were highly expe-rienced in cryptographic development Our results suggestthat organizational security mindsets are based on maturityand a strong security culture which in turn guide selectionof cryptographic resources and inform rigorous developmentand testing practices Based on these observations we seeopportunities for development organizations cryptographicresource providers and security researchers to facilitate anenvironment conducive to building the expertise required tocorrectly and securely implement cryptography

DisclaimerCertain commercial companies or products are identified inthis paper to foster understanding Such identification doesnot imply recommendation or endorsement by the NationalInstitute of Standards and Technology nor does it implythat the companies or products identified are necessarily the


best available for the purpose

AcknowledgementsThe authors would like to thank the following individu-als who offered insightful comments that helped improvethe quality of this paper the anonymous reviewers CurtBarker Sascha Fahl Simson Garfinkel Michelle MazurekMatthew Smith Brian Stanton and Jeff Voas

8 REFERENCES[1] Y Acar M Backes S Fahl S Garfinkel D Kim

M Mazurek and C Stransky Comparing theusability of cryptographic APIs In Proceedings of the38th IEEE Symposium on Security and Privacy 2017

[2] Y Acar M Backes S Fahl D Kim M L Mazurekand C Stransky You get where yoursquore looking forThe impact of information sources on code security InProceedings of the 37th IEEE Symposium on Securityand Privacy pages 289ndash305 May 2016

[3] American National Standards Institute ANSIhttpswwwansiorg 2018

[4] S Arzt S Nadi K Ali E Bodden S Erdweg andM Mezini Towards secure integration ofcryptographic software In Proceedings of the 2015ACM International Symposium on New Ideas NewParadigms and Reflections on Programming andSoftware (Onward rsquo15) pages 1ndash13 2015

[5] R S Barbour Checklists for improving rigour inqualitative research a case of the tail wagging thedog British Medical Journal 322(7294)1115ndash11172001

[6] C A Barry N Britten N Barber C Bradley andF Stevenson Using reflexivity to optimize teamworkin qualitative research Qualitative Health Research9(1)26ndash44 1999

[7] A Begel and B Simon Novice software developers allover again In Proceedings of the Fourth InternationalWorkshop on Computing Education Research pages3ndash14 2008

[8] D J Bernstein T Lange and P Schwabe Thesecurity impact of a new cryptographic library InProceedings of the International Conference onCryptology and Information Security (LatinCrypt rsquo12)pages 159ndash176 2012

[9] E Bonver and M Cohen Developing and retaining asecurity testing mindset IEEE Security amp Privacy6(5) 2008

[10] C Bravo-Lillo L F Cranor J Downs andS Komanduri Bridging the gap in computer securitywarnings A mental model approach IEEE Security ampPrivacy 9(2)18ndash26 2011

[11] H Brenner and U Kliebsch Dependence of weightedkappa coefficients on the number of categoriesEpidemiology pages 199ndash202 Mar 1996

[12] CMMI Institute What is capability maturity modelintegration (CMMI) httpcmmiinstitutecom

capability-maturity-model-integration 2018

[13] J Corbin and A Strauss Basics of QualitativeResearch Techniques and Procedures for DevelopingGrounded Theory Sage Publications Thousand OaksCA 4th edition 2015

[14] Dell Incorporated RSA Conference Where the worldtalks security httpswwwrsaconferencecom2018

[15] K DeSwert Calculating inter-coder reliability inmedia content analysis using Krippendorffrsquos AlphaTechnical report Center for Politics andCommunication 2012

[16] S I Donaldson and E J Grant-ValloneUnderstanding self-report bias in organizationalbehavior research Journal of Business andPsychology 17(2)245ndash260 2002

[17] T Duong and J Rizzo Cryptography in the web Thecase of cryptographic design flaws in ASPNET InProceedings of the 31st IEEE Symposium on Securityand Privacy pages 481ndash489 May 2011

[18] M Egele D Brumley Y Fratantonio and C KruegelAn empirical study of cryptographic misuse inAndroid applications In Proceedings of the 2013 ACMSIGSAC Conference on Computer amp CommunicationsSecurity (CCS rsquo13) pages 73ndash84 2013

[19] S Fahl M Harbach T Muders L BaumgartnerB Freisleben and M Smith Why Eve and Mallorylove Android An analysis of Android SSL(in)security In Proceedings of the 2012 ACMConference on Computer and CommunicationsSecurity (CCS rsquo12) pages 50ndash61 2012

[20] C Forler S Lucks and J Wenzel Designing the APIfor a cryptographic library A misuse-resistantapplication programming interface In Proceedings ofthe 17th Ada-Europe International Conference onReliable Software Technologies (Ada-Europe rsquo12)pages 75ndash88 2012

[21] D Freelon Recal3 Reliability for 3+ codershttpdfreelonorgutilsrecalfrontrecal3

[22] D G Freelon ReCal Intercoder reliability calculationas a web service International Journal of InternetScience 5(1)20ndash33 2010

[23] R Garcia J Thorpe and M MartinCrypto-Assistant Towards facilitating developerrsquosencryption of sensitive data In Proceedings of the 12thAnnual International Conference on Privacy Securityand Trust (PST rsquo14) pages 342ndash346 2014

[24] Gartner IT glossary Small and midsize business(SMB) httpwwwgartnercomit-glossarysmbs-small-and-midsize-businesses 2017

[25] M Georgiev S Iyengar S Jana R AnubhaiD Boneh and V Shmatikov The most dangerouscode in the world validating SSL certificates innon-browser software In Proceedings of the 2012 ACMConference on Computer and CommunicationsSecurity pages 38ndash49 Oct 2012

[26] B G Glaser and A L Strauss The Discovery ofGrounded theory Strategies for Qualitative ResearchTransaction Publishers 2009

[27] M Green and M Smith Developers are not theenemy The need for usable security APIs IEEESecurity amp Privacy 14(5)40ndash46 Sept 2016

[28] L Greenemeier NSA efforts to evade encryptiontechnology damaged US cryptography standardhttpswwwscientificamericancomarticle

nsa-nist-encryption-scandal Sept 2013

[29] G Guest A Bunce and L Johnson How many


interviews are enough An experiment with datasaturation and variability Field Methods 18(1)59ndash822006

[30] P Gutmann Lessons learned in implementing anddeploying crypto software In Proceedings of the 2002Usenix Security Symposium pages 315ndash325 2002

[31] J M Haney S L Garfinkel and M F TheofanosOrganizational practices in cryptographic developmentand testing In Proceedings of the 5th IEEEConference on Communications and Network Security(CNS rsquo17) Oct 2017

[32] B Headd The role of microbusinesses in the economyhttpswwwsbagovsitesdefaultfiles Feb2015

[33] R Hodson Analyzing Documentary Accounts (No128) Sage Publications 1999

[34] M Howard and S Lipner The security developmentlifecycle Vol 8 Microsoft Press Redmond WA 2006

[35] Institute of Electrical and Electronics Engineers IEEEStandards Association httpstandardsieeeorg2018

[36] International Organization for StandardizationStandards httpswwwisoorgstandardshtml2018

[37] Internet Engineering Task Force IETFhttpswwwietforg 2018

[38] S L Kanniah and M N Mahrin A review on factorsinfluencing implementation of secure softwaredevelopment practices World Academy of ScienceEngineering and Technology International Journal ofSocial Behavioral Educational Economic Businessand Industrial Engineering 10(8)3022 2016

[39] K Krippendorff Content Analysis An Introduction toits Methodology Sage 2004

[40] D Lazar H Chen X Wang and N Zeldovich Whydoes cryptographic software fail A case study andopen problems In Proceedings of the 5th Asia-PacificWorkshop on Systems (APSys rsquo14) pages 71ndash772014

[41] D Leaman National Institute of Standards andTechnology NVLAP Common Criteria testingNISTHB 150-20httpswwwnistgovsitesdefaultfiles

documentsnvlapNIST-HB-150-20-2014pdf 2014

[42] Y Li Y Zhang J Li and D Gu iCryptoTracerDynamic analysis on misuse of cryptography functionsin iOS applications In Proceedings of theInternational Conference on Network and SystemSecurity pages 349ndash362 Oct 2014

[43] G McGraw Software security IEEE Security ampPrivacy 2(2)80ndash83 2004

[44] C G Menk System security engineering capabilitymaturity model and evaluations Partners within theassurance framework httpscsrcnistgovcsrcmediapublicationsconference-paper199610

22proceedings-of-the-19th-nissc-1996

documentspaper010cmmtpeppdf 1996

[45] S Merriam and E Tisdell Qualitative Research AGuide to Design and Implementation John Wiley ampSons San Francisco CA 4 edition 2016

[46] J E Montandon H Borges D Felix and M T

Valente Documenting APIs with examples Lessonslearned with the APIMiner platform In Proceedings ofthe 20th IEEE Working Conference on ReverseEngineering (WCRE) pages 401ndash408 2013

[47] M M Muller Two controlled experiments concerningthe comparison of pair programming to peer reviewJournal of Systems and Software 78(2)166ndash179 2005

[48] S Nadi S Kruger M Mezini and E BoddenJumping through hoops Why do Java developersstruggle with cryptography APIs In Proceedings ofthe 38th International Conference on SoftwareEngineering (ICSE rsquo16) pages 935ndash946 2016

[49] National Institute of Standards and Technology FIPSPub 140-2 Security requirements for cryptographicmodules httpcsrcnistgovpublicationsfipsfips140-2fips1402pdf 2001

[50] National Institute of Standards and TechnologyCryptographic module validation programhttpscsrcnistgovprojects

cryptographic-module-validation-program 2016

[51] National Institute of Standards and TechnologyCryptographic algorithm validation program (CAVP)=httpcsrcnistgovgroupsSTMcavp 2017

[52] National Institute of Standards and TechnologyCryptographic standards and guidelineshttpscsrcnistgovProjects

Cryptographic-Standards-and-Guidelines 2018

[53] P Nguyen Can we trust cryptographic softwareCryptographic flaws in GNU privacy guard v1 23 InProceedings of the International Conference on theTheory and Applications of Cryptographic Techniquespages 555ndash570 2004

[54] Open Web Application Security Project OWASPsecure software development lifecycle projecthttpswwwowasporg 2017

[55] OpenSSL Software Foundation OpenSSLcryptography and SSLTLS toolkithttpswwwopensslorg 2018

[56] M Q Patton Qualitative research John Wiley ampSons San Francisco CA 2005

[57] PCI Security Standards Council PCI Security httpswwwpcisecuritystandardsorgpci_security2018

[58] B Potter and G McGraw Software security testingIEEE Security amp Privacy 2(5)81ndash85 2004

[59] J Saldana The Coding Manual for QualitativeResearchers Sage 3 edition 2015

[60] T Schlienger and S Teufel Information securityculture-From analysis to change South AfricanComputer Journal (31)46ndash52 2003

[61] B Schneier Why cryptography is harder than itlooks httpswwwschneiercomessaysarchives199701why_cryptography_ishtml 1997

[62] B Schneier The security mindset httpswwwschneiercomblogarchives200803 2008

[63] D Seltzer-Kelly S J Westwood and D MPena-Guzman A methodological self-study ofquantitizing Negotiating meaning and revealingmultiplicity Journal of Mixed Methods Research6(4)258ndash274 2012

[64] S Shuai D Guowei G Tao Y Tianchang and


S Chenjie Modelling analysis and auto-detection ofcryptographic misuse in Android applications InProceedings of the 12th IEEE InternationalConference on Dependable Autonomic and SecureComputing pages 75ndash80 Aug 2014

[65] Stack Exchange Stack overflowhttpsstackoverflowcom 2018

[66] J Sunshine S Egelman H Almuhimedi N Atri andL F Cranor Crying wolf An empirical study of SSLwarning effectiveness In USENIX SecuritySymposium pages 399ndash416 2009

[67] A S Tanenbaum Computer Networks 2Nd EditionPrentice-Hall Inc Upper Saddle River NJ USA1988

[68] The MITRE Corporation Common vulnerabilities andexposures (CVE) httpscvemitreorg 2018

[69] D R Thomas A general inductive approach foranalyzing qualitative evaluation data AmericanJournal of Evaluation 27(2)237ndash246 June 2006

[70] Underwriters Laboratories (UL) Certification httpsservicesulcomcategoriescertification2018

[71] US-CERT OpenSSL Heartbleed vulnerability(CVE-2014-0160)httpswwwus-certgovncasalertsTA14-098A2014

[72] Veracode The state of software securityhttpswwwveracodecomsitesdefaultfiles

ResourcesReports

state-of-software-security-volume-7-veracode-report

pdf 2016

[73] Veracode Veracode secure development surveyDevelopers respond to application security trendshttpsinfoveracodecom

report-veracode-developer-surveyhtml 2016

[74] L Williams R R Kessler W Cunningham andR Jeffries Strengthening the case for pairprogramming IEEE Software 17(4)19ndash25 2000

[75] S Xiao and E Witschey Jand Murphy-Hill Socialinfluences on secure development tool adoption Whysecurity tools spread In Proceedings of the 17th ACMconference on Computer supported Cooperative Workand Social Computing CSCW rsquo14 pages 1095ndash1106Feb 2014

[76] J Xie and B Lipford H Rand Chu Why doprogrammers make security errors In Proceedings ofthe 2011 IEEE Symposium on Visual Languages andHuman-Centric Computing pages 161ndash164 Sept2011


APPENDIX

A INTERVIEW QUESTIONS

1 Can you tell me about your organization - what it does what it produces

2 What is your role within your organization with respect to cryptographic products

3 How did you get into this field

(a) At what point and why did you become concerned with cryptography and secure development

(b) In which field(s) is your formal education

4 Do you work in a unit or department that is part of a larger organization

If yes What is the size of the unit or department

(a) What is the size of your overall organization

5 Can you tell me about the kinds of products your organization develops and specifically those that use cryptography

6 Who are the typical customers for your products that use cryptography

7 How long has your organization been working on products that use cryptography

8 Is cryptography your organizationrsquos primary business focus or is it an enabler within your products

9 For your products that use cryptography what processes or techniques if any does your organization use to minimizebugs and errors in code during the development process

(a) Why does your organization choose to use these methods [only use if participant has difficulty coming up withresponse] for example industry standard customer demand robustness and quality

10 What processes or techniques does your organization use to test and validate the cryptography component in yourproducts


(b) What kind of end-user testing if any does your organization do to prevent customers from misconfiguring or misusingthe cryptography component in your products

11 Does your organization do any certifications or third-party testing

(a) What reasons led you to decide to use certifications or third-party testing

(b) How do you establish confidence in the results of the certifications or third-party testing

(c) What are the challenges or issues your organization has experienced with certifications or third-party testing if any

12 What if any are your organizationrsquos biggest challenges with respect to developing and testing cryptography within yourproducts

(a) How do you think these challenges can be overcome if at all

(b) Has your organization experienced a tension between secure development and testing and getting a product tomarket If so how has that impacted your organizationrsquos processes

13 Do your customers have specific requirements regarding development and testing If so what are those requirements

14 How do updates impact your development and testing processes if at all (time-sensitive vs deprecation)

15 What resources do you use to help you develop and test the cryptography component of your products [only use ifparticipant has difficulty coming up with response] for example standards industry specifications books academicpapers standard libraries APIs

(a) What are the reasons your organization chooses to use those particular resources

If the participant does NOT use standards What are the reasons that your organization does not use standards

16 [If the participant uses standards] What kinds of standards do you use

(a) What is the role of standards in your organizationrsquos development and testing processes

(b) What do you see as the value or benefit of using these standards if any

17 How could standards or other cryptographic resources be improved to be more useful

(a) How could NIST standards and guidance be improved to be more useful

18 Is there anything else yoursquod like to add about the topics wersquove discussed


B CODEBOOK

Participant Demographics

Organization Demographics

Organization Characteristics

bull Team Interactions

bull Security Culture

bull Maturity

bull TalentHiring

Development and Testing Practices

bull Formal

bull Informal

bull Risk-based

bull Practices

ndash Automated

ndash HumanManual

ndash External3rd party testing

ndash End-user testing

bull ReasonsPhilosophy

bull Evolution

bull Confidence

bull Challenges

bull Updates

CertificationsCompliance Programs

bull Which ones (identify)

bull Problems and Challenges

bull Reasons

bull Confidence

bull Improvements

Resources

bull Standards

bull Government

bull Industry3rd Party

bull Internally developed

bull Research

bull Gaps

Security

bull Vulnerabilities and Errors

bull Usability and Complexity

bull Relationship and Tensions

Security Education

bull Customers

bull DevelopersEngineers

Emotions

bull Positive

bull Negative

Influences

Customers

Evolution of Security Field

Complaints

Participant Values and Perceptions

Trust


We make it a big deal in the company Security Mindsetsin Organizations that Develop Cryptographic Products

Julie M Haney1 Mary F Theofanos1 Yasemin Acar2 Sandra Spickard Prettyman3

1National Institute ofStandards and Technology

juliehaneymarytheofanosnistgov

2Leibniz University Hannoveracarsecuni-hannoverde

3Culture Catalystsspretty50icloudcom

ABSTRACTCryptography is an essential component of modern comput-ing Unfortunately implementing cryptography correctly isa non-trivial undertaking Past studies have supported thisobservation by revealing a multitude of errors and devel-oper pitfalls in the cryptographic implementations of soft-ware products However the emphasis of these studies wason individual developers there is an obvious gap in morethoroughly understanding cryptographic development prac-tices of organizations To address this gap we conducted 21in-depth interviews of highly experienced individuals rep-resenting organizations that include cryptography in theirproducts Our findings suggest a security mindset not seenin other research results demonstrated by strong organiza-tional security culture and the deep expertise of those per-forming cryptographic development This mindset in turnguides the careful selection of cryptographic resources andinforms formal rigorous development and testing practicesThe enhanced understanding of organizational practices en-courages additional research initiatives to explore variationsin those implementing cryptography which can aid in trans-ferring lessons learned from more security-mature organiza-tions to the broader development community through edu-cational opportunities tools and other mechanisms Thefindings also support past studies that suggest that the us-ability of cryptographic resources may be deficient and pro-vide additional suggestions for making these resources moreaccessible and usable to developers of varying skill levels

1 INTRODUCTIONIn a dynamic threat-laden and interconnected digital envi-ronment cryptography protects privacy provides for ano-nymity ensures the confidentiality and integrity of com-munications and safeguards sensitive information Giventhe need for cryptography there is an abundance of cryp-tographic algorithm and library choices for developers wish-ing to integrate cryptography into their products and ser-vices However developers often lack the expertise to navi-

Copyright is held by the authorowner Permission to make digital or hardcopies of all or part of this work for personal or classroom use is grantedwithout feeUSENIX Symposium on Usable Privacy and Security (SOUPS) 2018August 12ndash14 2018 Baltimore MD USA

gate these choices resulting in the introduction of securityvulnerabilities [27] A 2016 industry survey that includedover 300000 code assessments found that 39 of those ap-plications had cryptographic problems [72] Implementingcryptography correctly is a non-trivial undertaking

In 1997 security expert Bruce Schneier commented on thelack of cryptographic implementation rigor and expertise atthat time asserting ldquoYou canrsquot make systems secure bytacking on cryptography as an afterthought You have toknow what you are doing every step of the way from con-ception to installationrdquo [61] Past studies have supportedthis observation by revealing a multitude of errors in thecryptographic implementations of software products (eg[17ndash19 42]) and the pitfalls developers encounter when in-cluding cryptography within products (eg [1248]) Thisbody of research suggests that developers have not pro-gressed much in the past 20 years However as these stud-ies have been largely focused on individual practices out-side the professional work context or on the developmentof mobile apps it is unclear if these shortcomings also ap-ply to organizational development and testing particularlyamong organizations for which security and cryptographyare essential components One exploratory survey exam-ined high-level organizational practices in cryptographic de-velopment but lacked rich insight into actual practices andmotivators behind those [31] Clearly there is a gap in theliterature in more thoroughly understanding organizationalcryptographic development practices

To address this gap we performed a qualitative investigationinto the processes and resources that organizations employto ensure their cryptographic products are not fraught witherrors and vulnerabilities We define the scope of crypto-graphic products as those implementing cryptographic al-gorithms or using crypto (cryptography) to perform somefunction We conducted 21 in-depth interviews involvingparticipants representing organizations that develop eithera security product that uses cryptography or a non-securityproduct that heavily relies on cryptography Unlike previ-ous studies our participants were professionals who werehighly experienced in cryptographic development and test-ing not computer science students or developers with littlecryptographic experience

The study aimed to answer the following research questions

Q1 What are the cryptographic development and testingpractices of organizations





























































































































informs







Pentesting

SystemLeveltests

Certi-fication




Secure defaults


party resources

bug hunting

next iteration


development

testing







design reviews

code reviews

automated

external3rd party

withby end users 8

10

16

9

9










test vectors needed



3

3

3

7

6

19













6 IMPLICATIONS









































































































ResourcesReports


pdf 2016







APPENDIX






































B CODEBOOK






bull Maturity

bull TalentHiring


bull Formal

bull Informal

bull Risk-based

bull Practices

ndash Automated

ndash HumanManual




bull Evolution

bull Confidence

bull Challenges

bull Updates




bull Reasons

bull Confidence

bull Improvements

Resources

bull Standards

bull Government



bull Research

bull Gaps

Security




Security Education

bull Customers


Emotions

bull Positive

bull Negative

Influences

Customers


Complaints


Trust





























































































































informs







Pentesting

SystemLeveltests

Certi-fication




Secure defaults


party resources

bug hunting

next iteration


development

testing







design reviews

code reviews

automated

external3rd party

withby end users 8

10

16

9

9










test vectors needed



3

3

3

7

6

19













6 IMPLICATIONS









































































































ResourcesReports


pdf 2016







APPENDIX






































B CODEBOOK






bull Maturity

bull TalentHiring


bull Formal

bull Informal

bull Risk-based

bull Practices

ndash Automated

ndash HumanManual




bull Evolution

bull Confidence

bull Challenges

bull Updates




bull Reasons

bull Confidence

bull Improvements

Resources

bull Standards

bull Government



bull Research

bull Gaps

Security




Security Education

bull Customers


Emotions

bull Positive

bull Negative

Influences

Customers


Complaints


Trust


















































































































informs







Pentesting

SystemLeveltests

Certi-fication




Secure defaults


party resources

bug hunting

next iteration


development

testing







design reviews

code reviews

automated

external3rd party

withby end users 8

10

16

9

9










test vectors needed



3

3

3

7

6

19













6 IMPLICATIONS









































































































ResourcesReports


pdf 2016







APPENDIX






































B CODEBOOK






bull Maturity

bull TalentHiring


bull Formal

bull Informal

bull Risk-based

bull Practices

ndash Automated

ndash HumanManual




bull Evolution

bull Confidence

bull Challenges

bull Updates




bull Reasons

bull Confidence

bull Improvements

Resources

bull Standards

bull Government



bull Research

bull Gaps

Security




Security Education

bull Customers


Emotions

bull Positive

bull Negative

Influences

Customers


Complaints


Trust





































































































informs







Pentesting

SystemLeveltests

Certi-fication




Secure defaults


party resources

bug hunting

next iteration


development

testing







design reviews

code reviews

automated

external3rd party

withby end users 8

10

16

9

9










test vectors needed



3

3

3

7

6

19













6 IMPLICATIONS









































































































ResourcesReports


pdf 2016







APPENDIX






































B CODEBOOK






bull Maturity

bull TalentHiring


bull Formal

bull Informal

bull Risk-based

bull Practices

ndash Automated

ndash HumanManual




bull Evolution

bull Confidence

bull Challenges

bull Updates




bull Reasons

bull Confidence

bull Improvements

Resources

bull Standards

bull Government



bull Research

bull Gaps

Security




Security Education

bull Customers


Emotions

bull Positive

bull Negative

Influences

Customers


Complaints


Trust
























































































informs







Pentesting

SystemLeveltests

Certi-fication




Secure defaults


party resources

bug hunting

next iteration


development

testing







design reviews

code reviews

automated

external3rd party

withby end users 8

10

16

9

9










test vectors needed



3

3

3

7

6

19













6 IMPLICATIONS









































































































ResourcesReports


pdf 2016







APPENDIX






































B CODEBOOK






bull Maturity

bull TalentHiring


bull Formal

bull Informal

bull Risk-based

bull Practices

ndash Automated

ndash HumanManual




bull Evolution

bull Confidence

bull Challenges

bull Updates




bull Reasons

bull Confidence

bull Improvements

Resources

bull Standards

bull Government



bull Research

bull Gaps

Security




Security Education

bull Customers


Emotions

bull Positive

bull Negative

Influences

Customers


Complaints


Trust

































































informs







Pentesting

SystemLeveltests

Certi-fication




Secure defaults


party resources

bug hunting

next iteration


development

testing







design reviews

code reviews

automated

external3rd party

withby end users 8

10

16

9

9










test vectors needed



3

3

3

7

6

19













6 IMPLICATIONS









































































































ResourcesReports


pdf 2016







APPENDIX






































B CODEBOOK






bull Maturity

bull TalentHiring


bull Formal

bull Informal

bull Risk-based

bull Practices

ndash Automated

ndash HumanManual




bull Evolution

bull Confidence

bull Challenges

bull Updates




bull Reasons

bull Confidence

bull Improvements

Resources

bull Standards

bull Government



bull Research

bull Gaps

Security




Security Education

bull Customers


Emotions

bull Positive

bull Negative

Influences

Customers


Complaints


Trust

















































informs







Pentesting

SystemLeveltests

Certi-fication




Secure defaults


party resources

bug hunting

next iteration


development

testing







design reviews

code reviews

automated

external3rd party

withby end users 8

10

16

9

9










test vectors needed



3

3

3

7

6

19













6 IMPLICATIONS









































































































ResourcesReports


pdf 2016







APPENDIX






































B CODEBOOK






bull Maturity

bull TalentHiring


bull Formal

bull Informal

bull Risk-based

bull Practices

ndash Automated

ndash HumanManual




bull Evolution

bull Confidence

bull Challenges

bull Updates




bull Reasons

bull Confidence

bull Improvements

Resources

bull Standards

bull Government



bull Research

bull Gaps

Security




Security Education

bull Customers


Emotions

bull Positive

bull Negative

Influences

Customers


Complaints


Trust

































informs







Pentesting

SystemLeveltests

Certi-fication




Secure defaults


party resources

bug hunting

next iteration


development

testing







design reviews

code reviews

automated

external3rd party

withby end users 8

10

16

9

9










test vectors needed



3

3

3

7

6

19













6 IMPLICATIONS









































































































ResourcesReports


pdf 2016







APPENDIX






































B CODEBOOK






bull Maturity

bull TalentHiring


bull Formal

bull Informal

bull Risk-based

bull Practices

ndash Automated

ndash HumanManual




bull Evolution

bull Confidence

bull Challenges

bull Updates




bull Reasons

bull Confidence

bull Improvements

Resources

bull Standards

bull Government



bull Research

bull Gaps

Security




Security Education

bull Customers


Emotions

bull Positive

bull Negative

Influences

Customers


Complaints


Trust




















informs







Pentesting

SystemLeveltests

Certi-fication




Secure defaults


party resources

bug hunting

next iteration


development

testing







design reviews

code reviews

automated

external3rd party

withby end users 8

10

16

9

9










test vectors needed



3

3

3

7

6

19













6 IMPLICATIONS









































































































ResourcesReports


pdf 2016







APPENDIX






































B CODEBOOK






bull Maturity

bull TalentHiring


bull Formal

bull Informal

bull Risk-based

bull Practices

ndash Automated

ndash HumanManual




bull Evolution

bull Confidence

bull Challenges

bull Updates




bull Reasons

bull Confidence

bull Improvements

Resources

bull Standards

bull Government



bull Research

bull Gaps

Security




Security Education

bull Customers


Emotions

bull Positive

bull Negative

Influences

Customers


Complaints


Trust





informs







Pentesting

SystemLeveltests

Certi-fication




Secure defaults


party resources

bug hunting

next iteration


development

testing







design reviews

code reviews

automated

external3rd party

withby end users 8

10

16

9

9










test vectors needed



3

3

3

7

6

19













6 IMPLICATIONS









































































































ResourcesReports


pdf 2016







APPENDIX






































B CODEBOOK






bull Maturity

bull TalentHiring


bull Formal

bull Informal

bull Risk-based

bull Practices

ndash Automated

ndash HumanManual




bull Evolution

bull Confidence

bull Challenges

bull Updates




bull Reasons

bull Confidence

bull Improvements

Resources

bull Standards

bull Government



bull Research

bull Gaps

Security




Security Education

bull Customers


Emotions

bull Positive

bull Negative

Influences

Customers


Complaints


Trust






test vectors needed



3

3

3

7

6

19













6 IMPLICATIONS









































































































ResourcesReports


pdf 2016







APPENDIX






































B CODEBOOK






bull Maturity

bull TalentHiring


bull Formal

bull Informal

bull Risk-based

bull Practices

ndash Automated

ndash HumanManual




bull Evolution

bull Confidence

bull Challenges

bull Updates




bull Reasons

bull Confidence

bull Improvements

Resources

bull Standards

bull Government



bull Research

bull Gaps

Security




Security Education

bull Customers


Emotions

bull Positive

bull Negative

Influences

Customers


Complaints


Trust






































































































ResourcesReports


pdf 2016







APPENDIX






































B CODEBOOK






bull Maturity

bull TalentHiring


bull Formal

bull Informal

bull Risk-based

bull Practices

ndash Automated

ndash HumanManual




bull Evolution

bull Confidence

bull Challenges

bull Updates




bull Reasons

bull Confidence

bull Improvements

Resources

bull Standards

bull Government



bull Research

bull Gaps

Security




Security Education

bull Customers


Emotions

bull Positive

bull Negative

Influences

Customers


Complaints


Trust

























































































ResourcesReports


pdf 2016







APPENDIX






































B CODEBOOK






bull Maturity

bull TalentHiring


bull Formal

bull Informal

bull Risk-based

bull Practices

ndash Automated

ndash HumanManual




bull Evolution

bull Confidence

bull Challenges

bull Updates




bull Reasons

bull Confidence

bull Improvements

Resources

bull Standards

bull Government



bull Research

bull Gaps

Security




Security Education

bull Customers


Emotions

bull Positive

bull Negative

Influences

Customers


Complaints


Trust






















































ResourcesReports


pdf 2016







APPENDIX






































B CODEBOOK






bull Maturity

bull TalentHiring


bull Formal

bull Informal

bull Risk-based

bull Practices

ndash Automated

ndash HumanManual




bull Evolution

bull Confidence

bull Challenges

bull Updates




bull Reasons

bull Confidence

bull Improvements

Resources

bull Standards

bull Government



bull Research

bull Gaps

Security




Security Education

bull Customers


Emotions

bull Positive

bull Negative

Influences

Customers


Complaints


Trust











ResourcesReports


pdf 2016







APPENDIX






































B CODEBOOK






bull Maturity

bull TalentHiring


bull Formal

bull Informal

bull Risk-based

bull Practices

ndash Automated

ndash HumanManual




bull Evolution

bull Confidence

bull Challenges

bull Updates




bull Reasons

bull Confidence

bull Improvements

Resources

bull Standards

bull Government



bull Research

bull Gaps

Security




Security Education

bull Customers


Emotions

bull Positive

bull Negative

Influences

Customers


Complaints


Trust


APPENDIX






































B CODEBOOK






bull Maturity

bull TalentHiring


bull Formal

bull Informal

bull Risk-based

bull Practices

ndash Automated

ndash HumanManual




bull Evolution

bull Confidence

bull Challenges

bull Updates




bull Reasons

bull Confidence

bull Improvements

Resources

bull Standards

bull Government



bull Research

bull Gaps

Security




Security Education

bull Customers


Emotions

bull Positive

bull Negative

Influences

Customers


Complaints


Trust


B CODEBOOK






bull Maturity

bull TalentHiring


bull Formal

bull Informal

bull Risk-based

bull Practices

ndash Automated

ndash HumanManual




bull Evolution

bull Confidence

bull Challenges

bull Updates




bull Reasons

bull Confidence

bull Improvements

Resources

bull Standards

bull Government



bull Research

bull Gaps

Security




Security Education

bull Customers


Emotions

bull Positive

bull Negative

Influences

Customers


Complaints


Trust


Documents

“We make it a big deal in the company”: Security Mindsets ... · velopment and testing practices since even the best imple-mented cryptography can be subverted by the awed im-plementation