WIXLIB

editor@issa.orgThank you and looking forward toa new year!Editor: Thom Barrieeditor@issa.orgJoel M. Weise – Chairman, Editorial Advisory Board andAdvertising: vendor@issa.orgISSA Distinguished Fellow866 349 5818 1 206 388 4584AEditorial Advisory Boardnd so ends another trip around the sun for the ISSAJournal. Is it me or does it seem like the years go byfaster?I would like to close this year out with a thank you to our membership; the many contributors and authors that provided articles, columns, editorials, and feedback; our International Board for their unwavering support; theJournal’s Editorial Advisory Board for their dedication and hard work in reviewingall of the Journal’s content; and Thom Barrie, our editor, for bringing it all together.Phillip Griffin, FellowMichael Grimaila, FellowJohn Jordan, Senior MemberMollie Krehnke, FellowJoe Malec, FellowDonn Parker, Distinguished FellowKris TanakaI look forward to another year of the Journal. There are many security, privacy, governance, and other issues we continue to face, and I am sure there will be many tocome that we cannot even anticipate. My only ask of the membership is please contribute. This is your Journal. It is only as good as your participation.Joel Weise – Chairman,Distinguished FellowBranden Williams,Distinguished FellowWe all should be looking for ways to stay engaged and help influence the world ofinformation security.Services DirectoryJoel M. WeiseWebsitewebmaster@issa.orgAs the year winds down, across the globe many of our membershipare looking forward to the holidays. We wish you all thewarmth of family and friends.866 349 5818 1 206 388 4584We wish you a time of respite from the constant battles of work,travel, commute; We wish you a pause in the incessantkeeping of the wolves at bay.866 349 5818 1 206 388 4584But as one put it: rust never sleeps. And neither do those bent onwreaking havoc, bent on thieving and destroying, bent on laying wasteto our personal security, our financial security, even our national security.866 349 5818 1 206 388 4584Chapter Relationschapter@issa.orgMember Relationsmember@issa.orgExecutive Directorexecdir@issa.orgSo, do relax and enjoy some brief and fleeting moments of rest;revitalize yourselves as you continue to fight the fight,day in and day out, year in and year out.Advertising and SponsorshipsHappy Holidays and a Prosperous New Year!866 349 5818 1 206 388 4584The information and articles in this magazine have not been subjected to anyformal testing by Information SystemsSecurity Association, Inc. The implementation, use and/or selection of software,hardware, or procedures presentedwithin this publication and the resultsobtained from such selection or implementation, is the responsibility of thereader.Articles and information will be presented as technically correct as possible, to4 – ISSA Journal December 2016the best knowledge of the author andeditors. If the reader intends to makeuse of any of the information presentedin this publication, please verify and testany and all procedures selected. Technical inaccuracies may arise from printingerrors, new developments in the industry, and/or changes/enhancements tohardware or software components.The opinions expressed by the authorswho contribute to the ISSA Journal aretheir own and do not necessarily reflect866 349 5818 1 206 388 4584vendor@issa.orgthe official policy of ISSA. Articles maybe submitted by members of ISSA. Thearticles should be within the scope of information systems security, and shouldbe a subject of interest to the membersand based on the author’s experience.Please call or write for more information.Upon publication, all letters, stories, andarticles become the property of ISSAand may be distributed to, and used by,all of its members.ISSA is a not-for-profit, independent cor-poration and is not owned in whole or inpart by any manufacturer of software orhardware. All corporate information security professionals are welcome to joinISSA. For information on joining ISSAand for membership rates, see www.issa.org.All product names and visual representations published in this magazine arethe trademarks/registered trademarksof their respective manufacturers.

Sabett’s BriefSecurity Architecture and the USCongress?By Randy V. Sabett – ISSA Senior Member, Northern Virginia ChapterUnless you follow Congressclosely you may have missedtheir recent foray into security and Internet architecture. Some ofthings that have been discussed, however, actually reflect a viewpoint of one ofmy very smart friends who knows a lotabout this. His approach (several yearsback) would be to completely re-architect the Internet from the ground up tomake it secure. As he has stated, “humans built this thing; humans can tearit down and re-build it.”So, as a result of high-profile attacksusing IoT devices that have highlightedsecurity vulnerabilities, some witnessesat a recent House hearing have called fordirect government regulation. Housemembers, however, struck a more cautionary note, calling for greater coordination and adoption of best practices.Coincidentally, immediately prior to theHouse hearing, NIST released best practices guidance for engineers developingIoT devices. Industry failure to adoptsuch practices will likely heighten regulators’ resolve to prescribe standards,especially if disruptive attacks continue.IoT security hearing by the House Energyand Commerce CommitteeThe committee held a hearing on November 16 to examine the role of theIoT in recent cyber attacks that involved hacked consumer IoT devices.Bruce Schneier characterized the DDoSattacks as a fundamental market failure: “[Y]our security on the Internetdepends on the security of millions ofInternet-enabled devices, designed andsold by companies you’ve never heardof to consumers who don’t care aboutyour security [T]he market has prioritized features and costs over security.” Schneier encouraged the Housecommittee to take action: “[T]he onlysolution is to regulate. The governmentcould impose minimum security standards on IoT manufacturers, forcingthem to make their devices secure eventhough their customers don’t care. [Doing so] would raise the cost of insecurityand give companies incentives to spendmoney making their devices secure.”Another witness stated that “there maybe a role for the government to provideappropriate guidance.”While expressing concern over the risksassociated with connected devices, themembers of the House committee werehesitant to endorse legislation as thesolution, in part due to concerns overstifling innovation in this burgeoningindustry. As stated by the HonorableGreg P. Walden, chairman of the Subcommittee on Communications andTechnology: “How do we make ourselves more secure without sacrificingthe benefits of innovation and technological advances? The knee-jerk reaction might be to regulate the Internet ofThings, and while I am not taking thatoff the table, the question is whether weneed a more holistic solution.”NIST guidance for engineering trustworthysecure systemsThe House committee recognized NISTas the author of a set of security recommendations to which industry and government can look for guidance. NISTSpecial Publication (SP) 800-160, Systems Security Engineering, representsa holistic approach to creating trustworthy and secure systems, encouragingthe incorporation of engineering-basedsecurity design principles into the basicarchitecture and design of a system.The document states at the very beginning that it is meant to be used in a veryflexible fashion, inorder to meet theneeds of a diverseset of stakeholders. Additionally, it is “not intended toprovide a specific recipe for execution.”Thus, Chapter Two begins with an overview discussion of the discipline of systems security engineering, including descriptions of a system, the elements of asystem, and the associated environment.It then describes a system from a security perspective and introduces conceptsthat allow the system to be appropriatelydeconstructed. Chapter Three discussesthe processes that define a system life cycle that leads to security. These includeagreement negotiations, organizationalproject-enabling processes, technicalmanagement processes, and detailedtechnical processes. Clearly this is nota document to be consumed by just onetype of stakeholder.So, I’m now going to kick back with anRFID-tagged beer that I pulled from myInternet-connected fridge (the same oneI mentioned in my June column), turn onmy smart TV, tell my copycat voice-recognition device to find out what’s onC-SPAN, and instead wind up watchingthe game on my tablet though I can’tunderstand why all my favorite sites areso slow or completely down About the AuthorRandy V. Sabett, J.D., CISSP, is SpecialCounsel at Cooley LLP (www.cooley.com), and a member of the Boards ofDirectors of ISSA NOVA and the Georgetown Cybersecurity Law Institute. Hewas a member of the Commission on Cybersecurity for the 44th Presidency, wasnamed the ISSA Professional of the Yearfor 2013, and can be reached at rsabett@cooley.com.December 2016 ISSA Journal – 5

Herding CatsWrite That DownBy Branden R. Williams – ISSA Distinguished Fellow, North Texas ChapterEvery so often, I helpout my dadwithinformationtechnology and security projects. Those who have heardme speak know I sometimes pick on mydad when it comes to information technology around the home, but when itcomes to the office, he’s the guy who getscalled when stuff breaks. He’s on top ofhis game when it comes to the office, andhe won’t take on any challenge withoutknowing he has a solid support structure (that isn’t me, by the way) to helphim when stuff breaks.Oh, and for reference, my dad has anundergrad in marketing and a generalstudies MBA (almost sounds like someone else you know, right?), so IT is not inhis training, but somehow it ended up inhis bailiwick.There are times when we have debatesabout technology or business strategy, and I’ll bring up something arounddocumentation. The default reaction isusually, “Son, that’s big company stuff.We’re a small company.” I sometimeshave to remind him that I was once ina company of two—quite smaller thanhis—and we had some of these basicthings documented almost twenty yearsago. Small companies tend to be morenimble and reactive, which means thatthings like months of planning and documentation before investing in a product just doesn’t happen.Companies in the financial servicessector tend to be really good at creatingdocumentation—almost to a fault. I’veworked for a few over my career andhave consulted with dozens. Documentation for the sake of documentation—that is, without a valuable purpose otherthan to check a box or make an auditor6 – ISSA Journal December 2016happy—is tough to justify spendingtime on to get it right. As a consultant,I’ve read through thousands of pages ofdocumentation that resembled a “justget it done so we can clear an audit finding” or “fill out this form so we can passthrough the gate.” It was as painful toreview as it was to write.When documentation is done right, itforces us to have tough conversationsbefore products or projects get too fardown the implementation path. Imagine for a second that Target had a robustremote access documentation process,including continual validation of thoserequirements, for the remote management of HVAC equipment. By robust,I mean complete and effective. Perhapsthey did have forms and help-desk tickets, but the process was broken, leadingto the well-publicized incident we oftenquote. Had their process been effective,would they even be top-of-mind when itcomes to big retail breaches?One of my favorite areas of security architecture is ensuring business alignment. It’s the documentation that showsall the business and security requirements that must be met before something can move from planning to designphase. These are the discussions thatwill allow the security team to ensuretheir basic requirements are met whilesimultaneously introducing additionalrequirements based on risk or customized to the project itself. If you do thiscorrectly, all of the controls associatedwith those requirements can be included early enough to adjust the businessmodel to account for unrealized risks.Let’s bring this full circle. Documentation is not just a big company thing—it’san every company thing. It’s critical toyour security architecture process as itforces the tough security conversationsearly. It should be a valuable investmentfor current employees, auditors andthe audit process, and future employees to understand the why of your operations. It’s not something that can betaken lightly, but done right, it’s worththe investment. You must allocate resources to maintain and review yourdocumentation, and you must convinceyour superiors that it is worth the resource investment. Connect the dots forthem and show them how current andfuture processes can benefit from useful documentation. Remember, gooddocumentation is alive. It will change asyour company changes. It should evolveto represent the current state of things.It is a reference for future employeeswho come in after you and a tome forcurrent employees on your team or in across-functional role.By the way, I’m just seeing if people readdown this far (and padding my wordcount for Thom). Given that it’s the holiday season, tweet something about thisarticle and tag me (@BrandenWilliams).I will enter all those who do so into arandom drawing for a 25 Amazon giftcard. Happy holidays!About the AuthorBranden R. Williams, DBA, CISSP,CISM, is a seasoned infosec and payments executive, ISSA DistinguishedFellow, and regularly assists top globalfirms with their information security andtechnology initiatives. Read his blog, buyhis books, or reach him directly at www.brandenwilliams.com/.

Open ForumThe Open Forum is a vehicle for individuals to provide opinions or commentaries on infosec ideas, technologies, strategies, legislation, standards, and other topics of interest tothe ISSA community. The views expressed in this column are the author’s and do not reflect the position of the ISSA, the ISSA Journal, or the Editorial Advisory Board.The Security Architect and theSecurity EngineerBy David Mashburn and Stephen Northcutt – ISSA member, Puget Sound ChaperTwo essential roles for successfulsecurity operations in mid-sizedor larger organizations are security architect and security engineer. Inthe competitive job market for skilledIT security professionals, it might appear that the two roles and skill sets arenearly interchangeable. However, thereare some significant differences in scopeand perspective between the two roles.These differences should be consideredcarefully as part of the hiring processto make sure that the candidate mosteffectively meets the needs of the organization.Security engineer is a common job titlein many organizations. The skills required for this role usually target a specific domain of security expertise withan emphasis on relevant technologiesor products. Examples of job requirements or desired skill sets taken fromjob postings for security engineers include phrases such as “skilled with PKIin a Windows Active Directory environment” and “experience with the maintenance and upgrading of firewalls,specifically Checkpoint and Palo Alto,”highlighting the focus on these important, but possibly narrowly focused andvendor-specific areas of expertise withinthe security operations of the organization.If you compare those examples with thefollowing skill requirements taken froma job description posted online for asenior security architect, the followingattributes are expected from the candidate: “network security, network hardware configuration, network protocols,networking standards, supervision,conceptual skills, decision making, informing others, functional and technical skills, dependability, informationsecurity policies.” Note the descriptionsare less vendor or product specific, reflecting the differing role of the securityarchitect.The security architect designs a defensible architecture that is aligned withthe risk tolerance and risk profile of theorganization. The architect views security through the lens of organizationalneed, where the priority is understanding what the organization values, wherethe organizational assets are located,and how adversaries are most likely totry access that data. The architect mustbe able to present ideas and designs tovastly different audiences, ranging fromtechnical groups to managers includingthe C-suite. Because of these priorities,the security architect must not be lockedinto a product- or vendor-centric view ofsecurity and be open to alternatives.A broad comparison of the two roles reveals the relationships between the twojobs. There are overlaps but also fundamentally different expectations of eachrole in the security organization.Security architecture is strategic, whilesecurity engineering is often tactical bynature. The architect understands notonly the desired end state of a projectfrom the security perspective but alsohow that aligns with the overall organizational objectives; while a securityengineer may primarily be interested inthe most efficient and effective way tocomplete the project from the perspective of IT security.The security architect designs solutionsbased on principles of defensible security architecture, leveraging defensein-depth, data-centric security, andvisibility, providing opportunities tobreak the exploit kill chain. The security engineer is more likely to implementthe individual components of the solutions that comprise the entire securityarchitecture, such as firewalls, IPS orIDS, anti-malware products, file integrity monitoring, and data loss preventionsolutions. These are essential elements ofthe organizational security, but an engineer is more likely focused on the specific technology or vendor rather than howall of the elements are combined into theeffective end state.For aspiring security architects, thereare a growing number of training andcertification resources available. Certifications developed for IT security architects often include training offerings.The (ISC)2 organization has createdan ISSAP (Information Systems Security Architecture Professional) certification. The SABSA organization offers aset of integrated frameworks—models,methods, and processes—that can beutilized independently or as part of anintegrated enterprise solution.The TOGAF standard and certificationprogram specifically addresses enterprise architecture. While not intendedfor the security practitioner, these resources could prove valuable in establishing the required business perspecContinued on page 44December 2016 ISSA Journal – 7

Gray HatA Downside to Red TeamingBy Mark Anderson – ISSA member, Australia ChapterRed Teamingis seen bymany as avery effective meansto test the defense ofa network. Basically,a team of white hats defend a network,and an opposing team of black hats undertake attacks. At the end, a penetration report is written and can be used tostrengthen a network’s defenses. Soundslike a good idea doesn’t it, and in manyinstances where vulnerabilities havebeen discovered and closed off, this is aproactive win before an attacker can usean exploit. However, I want to list somehidden costs that can make the exercisepyrrhic if not managed very carefully.I will refer to a couple aspects of two redteaming efforts my staff and I were involved in where we had our white hatson, supporting the defending team oflarge classified operational networks.When you are “pen” testing a live, operational network, it’s a bad idea to activatewide-scale responses (e.g., lockdown) ifthe penetration detected is part of theblack hat activities for red teaming. So,one of the typical rules of engagement(ROE) includes the presence of a “trusted agent.” This agent in one of the exercises was an unknown member of thewhite hat team who had knowledge ofan attack by the black hats and can thendeclare it if the defenders start a massivelock down.But this seemingly good idea can backfire. Basically, in the first exercise, I observed all the white hats trying to figureout who the trusted agent was and wereworried that if the black hats trustedthis person then maybe they would doa “double agent” and apprise the blackhats of current tactics. In trying to ferretout the identity, distrust was sown rightacross the team. Unsurprisingly, the8 – ISSA Journal December 2016team was no longer a team, and it wasclear that its effectiveness in defendingthe network became seriously compromised. Any competent military commander can tell you that trust amongstyour unit is vital, and it was mesmerizing when I visited the network site forupgrades during the exercise to see theteam’s disintegration. It was amazingto me that we managed to detect anyattacks at all; and we got burnt by theblack hats.Given knowledge of previous culturalissues, I was given strict orders to cooperate with the black hats in anotherexercise to test one of my technologies,as this was a “one team” exercise; therewere criteria for the test to set the ROEand a marking scheme that the testingorganization comprising the black hatswould fill (that’s right, the attackers decided unilaterally on the score). Muchbetter you would think? Firstly, a blackhat turned up to look at our signaturefile citing “one team”; they stated laterit was part of social engineering. Theylater supplied us with a signature of oneof their attacks, but it was modified soit couldn’t work, and I wasn’t allowedto remodify it to work, given the ROE.In the end, we actually passed the testmuch to the black hats’ chagrin but laterfound out they then added other secrettests with hidden criteria. One of the responses was that the genuine adversarydoesn’t follow a ROE, so why shouldthey?In the cases I alluded to, it destroyedfriendships, entrenched a sour relationship between organizations, and causedsignificant loss of expertise. The testingorganization senior management didwrite a memo to a three-star rank military committee where they noted thatmy team had signifi

CISSP, Fellow Treasurer/Chief Financial Officer Pamela Fusco Distinguished Fellow Board of Directors Debbie Christofferson, CISM, CISSP, CIPP/IT, Distinguished Fellow Mary Ann Davidson Distinguished Fellow Rhonda Farrell, Fellow Geoff Harris, CISSP, ITPC, BSc, DipEE, CEng, CLAS, Fello