Year: 2016

Posted on

What You Need to Know: Navigating EU Data Protection Changes – EU-US Privacy Shield and EU General Data Protection Regulation

If you’re an organization with trans-Atlantic presence that transmits and stores European citizen data (e.g. employee payroll & HR data, client & prospect data) in the U.S. you will want to pay attention. What we will discuss was administered under the European Union’s Data Protection Directive and a previous EU-U.S. agreement called Safe Harbor.  We will cover what happened, what’s next, new rules (and penalties) that are set to go into effect and our recommendations.

What Happened?
Safe Harbor, invalidated by a European Court of Justice (ECJ) ruling (PDF) in October 2015, allowed companies to transmit and store EU citizen data in the US so long as the U.S. companies agreed to meet requirements as described in Decision 2000/520/EC otherwise known as ‘Safe Harbor Privacy Principles’. The European Court of Justice ruled to invalidate the Safe Harbor agreement as it determined that US companies were not able to meet Safe Harbor Privacy Principles as they conflicted with National Security Agency or other government agency subpoenas request for information and other government data collection programs.  Data on EU citizens was found as a result of US government surveillance program information being made public. In other words, if U.S. companies were complying with Safe Harbor Privacy Principles, that information would not have been found or made public as a result of those programs.

What’s Next…
In early February 2016, the US Department of Commerce and the European Commission announced a new framework called the Privacy Shield. Since then, a group known as the Article 29 Working Party, Europe’s data protection body, issued its own statement (PDF) about the Privacy Shield framework and expressed their reservations regarding the adequacy of the “Privacy Shield.” On July 8, 2016 the European Union Member States Representatives approved the final version of the Privacy Shield. The new Privacy Shield framework allows for transatlantic data transmission and outlines obligations on companies handling the data, in addition to written assurances from the U.S. that among other items rules out indiscriminate mass surveillance of European citizens’ data.

Additionally, in early 2016 the European Union enacted a new data protection framework that has been in the works since 2012, known as the General Data Protection Regulation. This new Regulation repeals and replaces the pre-existing European Union’s Data Protection Directive. While not much has changed in the new ‘Regulation’ U.S. companies should note that policies and procedures as it relates to employee data transmission from the EU to U.S. be updated as well as be aware of new penalties. The new rules of the Regulation (and penalties) “will become applicable two years thereafter.” So, in 2018, the rules and penalties around the General Data Protection Regulation will go into effect.

New Rules that will go into effect (enforceable, starting in January 2018):

  • Strong obligations on companies handling Europeans’ personal data and robust enforcement:U.S. companies wishing to import personal data from Europe will need to commit to robust obligations on how personal data is processed and individual rights are guaranteed. The Department of Commerce will monitor that companies publish their commitments, which makes them enforceable under U.S. law by the US. Federal Trade Commission. In addition, any company handling human resources data from Europe has to commit to comply with decisions by European DPAs.
  • Clear safeguards and transparency obligations on U.S. government access: For the first time, the US has given the EU written assurances that the access of public authorities for law enforcement and national security will be subject to clear limitations, safeguards and oversight mechanisms. These exceptions must be used only to the extent necessary and proportionate. The U.S. has ruled out indiscriminate mass surveillance on the personal data transferred to the US under the new arrangement. To regularly monitor the functioning of the arrangement there will be an annual joint review, which will also include the issue of national security access. The European Commission and the U.S. Department of Commerce will conduct the review and invite national intelligence experts from the U.S. and European Data Protection Authorities to it.
  • Effective protection of EU citizens’ rights with several redress possibilities: Any citizen who considers that their data has been misused under the new arrangement will have several redress possibilities. Companies have deadlines to reply to complaints. European DPAs can refer complaints to the Department of Commerce and the Federal Trade Commission. In addition, Alternative Dispute resolution will be free of charge. For complaints on possible access by national intelligence authorities, a new Ombudsperson will be created.

New Penalties that will go into effect (enforceable, starting in January 2018):
Under Article 79 of the Regulation, penalties and enforcements are described for Organizations less than 250 personnel and Enterprises. Violations of certain provisions for Enterprise organizations (> 250 employees) will carry a penalty of “up to 2% of total worldwide annual [revenue] of the preceding financial year.” Violations of other provisions will carry a penalty of “up to 4% of total worldwide annual [revenue] of the preceding financial year.”  The 4% penalty applies to “basic principles for processing, including conditionals for consent,” as well as “data subjects’ rights” and “transfers of personal data to a recipient in a third country or an international organization.”

What should U.S. companies consider?
There are a few options we’ll highlight here such as conducting Privacy Assessments with Privacy Shield and GDPR regulations in mind, ISO 27001 / 27018 certification, cyber risk program development to include vendor risk management, incident response planning and cyber risk assessments.

What to do – Privacy Shield
As it relates to the new EU-U.S. Privacy Shield, companies should review and be aware of the legal requirements outlined in the Privacy Shield (PDF). For certified Safe Harbor organizations, continue to abide by those elements within Safe Harbor, as you still have an obligation to protect EU data transfers, and begin to incorporate the Privacy Shield requirements as you will have to obtain certification (in-house or third-party) to gain listing on the Privacy Shield website maintained by the Department of Commerce.

Specifically, “It requires participating U.S. organization to develop a conforming privacy policy, publicly commit to comply with the Privacy Shield Principles so that the commitment becomes enforceable under U.S. law, annually re-certify their compliance to the Department (of Commerce), provide free independent dispute resolution, to EU individuals, and be subject to the authority of the U.S. Federal Trade Commission (“FTC”), Department of Transportation (“DOT”), or another enforcement agency.”

New requirements for Privacy Shield participating companies as outlined on the Commerce.gov site include:

  • Informing individuals about data processing
  • Maintaining Data Integrity and purpose limitation
  • Ensuring accountability for data transferred to third parties
  • Cooperating with the Department of Commerce
  • Transparency related to enforcement actions
  • Ensuring commitments are kept as long as data is held

What to do – EU GDPR
Under the new EU General Data Protection Regulation (Chapter 4, Section 2), not only is there also a requirement for an annual assessment, but the Regulation requires for data breach notification, incident response planning and security awareness training for staff involved in the data transmission process.

As it pertains to incident response plan and handling, the regulation stipulates notification to a supervisory authority within the European Union within 24 hours and notification to data owners without undue delay. Having an incident response plan in place will be critical to an organizations ability to respond to a data compromise incident.

On vendor risk management, Article 26 stipulates that subcontractors cannot process or transmit data on behalf of the organization (e.g Data controller). Since most organizations have programs for vendors to access systems or assist in data management, you’ll want to evaluate your vendors’ security and risk posture, since you could be affected by their negligence and entangled into one of those 2% or 4% of total revenue fine situations.

There are many other certifications and services that organizations should consider if they are not being done already including ISO 27001/27018 certification and attestation, privacy assessments and vendor risk management services to ensure data processors participate with Privacy Shield requirements and GDPR regulations.

ISO 27001 AND 27018 Certifications are an international security framework for securing information systems. ISO 27001 establishes an Information Security Management System and is an independent verification that your organization meets the ISO 27001 security standard.

ISO 27018 is a compliment to ISO 27001 and specifically focuses on protecting Personally Identifiable Information (PII) transmission and storage in the cloud. For Data Controllers and Data processors, meeting ISO 27018 will provide your organization with a method to establish control objectives, controls and guidelines for implementing measures to protect PII in the cloud in accordance with privacy principles in ISO/IEC 29100.

In Conclusion
The finalized Privacy Shield and the updated EU General Data Protection Regulation will require U.S. Companies to make EU citizen privacy a paramount priority to avoid any ramifications from EU regulations. Contact Coalfire to discuss any of the above information. Where needed we can also pull in our partner law firm to further educate and provide guidance on the updated EU privacy and data changes.

Marshall England, Industry Marketing Director, Technology & Cloud, Coalfire

[Cloud Security Alliance Blog]

Posted on

How to Track Actors Behind Keyloggers Using Embedded Credentials

Mo’ key loggers, mo’ problems

This past year Unit 42 has seen a resurgence of keylogger activity and it seems like every week a new research blog comes out talking about one of four popular families: KeyBase, iSpy,HawkEye, or PredatorPain. These blogs usually delve into the technical workings of the threats, discuss their relationship to each other, and explain how they evolved from one another through new ownership or branding of the tools. The intent of this blog is not to rehash what has already been discussed, but instead to shift the focus to the actors behind these keylogger threats and show a practical technique for identification.

To be of any value, keyloggers must transmit data back to the attacker. There are three well-established methods for doing this: HTTP, SMTP, and FTP. HTTP transmission usually involves a simple POST request with a body containing the stolen data; however, for SMTP and FTP, more often than not these protocols require authentication to log into a service before transferring the data from the compromised system. This presents a valuable data point, because all of the big four keylogger families embed their credentials inside of their binaries. This further provides an analyst with a remote server address, username, and password for each sample analyzed. Couple this with the increase of keyloggers found in the wild and we find ourselves with a very large data set that can be used for correlation.

By using Palo Alto Networks AutoFocus, I was able to quickly identify 500 recent samples of HawkEye and iSpy, which exhibited either FTP or SMTP activity during dynamic analysis. After downloading the samples and their respective network activity, I parsed out all successful FTP and SMTP activity to build a data set for Maltego. We’ll use these embedded credentials to try to uncover patterns and find actor-identifiable data through our research.

Before getting into the correlation, some general statistics on the data:

  • 207 FTP connections were caught with active credentials, e.g., the malware successfully logged into the FTP server to upload data from our virtual test machines
  • 53 SMTP connections were made with active credentials
  • 37 unique drop destinations were identified for stolen data
  • 96 unique accounts used to log into these drop sites

After collecting all of the data from PCAPs and loading it into Maltego, we can visually see multiple organic clusters standout along the top, which will be the topic for discussion.

Figure 1. Key logger clusters

Actor 01 (“Kramer”)

Starting from right to left, the first cluster shows a heavy concentration of samples communicating with IP address, 108.179.196[.]24. This FTP drop site was the most utilized across our sample set, with 71 unique samples and 18 unique FTP accounts being used to drop data.

Figure 2. The “Kramer” cluster

Looking a little closer, there is a smaller cluster of accounts on the left of the graph that warrants further investigation.

Figure 3. Unique password reuse in the “Kramer” cluster

While all the stolen data being dropped on one FTP server is a solid relational indicator, what’s even stronger is that 14 usernames all used the same password, “joinkrama2”. When you look at the actual accounts as well, we see usernames are formatted like e-mail addresses and some of the local parts of the address get shared across domains. The below list highlights some of these shared local parts across domains in the username. The domains themselves have been truncated.

  • chekube@her
  • chima@min
  • daniel@her
  • daniel@oma
  • dubem@sam
  • golden@sam
  • okumen@oma
  • oni@pea
  • oni@sas
  • udobata@sam
  • victor@sam
  • wizzy@pea
  • wizzy@sas

This correlation provides strong evidence that the actor behind these accounts is the same. We’re also able to pivot from the unique password to another account hanging off the bottom in the first image, which shares a local name with the above local, “dubem”. The sample in question is also seen dumping key logged data to a separate server at 68.171.217[.]250. Finally, one of the “oni” accounts from the above list was also seen using the password “pereyikelamo2”, which was tied to one other account using the same domain, “atus@sas”.

By following these links we can slowly begin mapping out part of the infrastructure utilized by this actor and collect multiple indicators to identify them.

Top Indicators for Actor 01 “Kramer”:

  • 108.179.196[.]24
  • 68.171.217[.]250
  • Chimaeze12
  • LAURINA12
  • chimaeze12
  • joinkrama2
  • pereyikelamo2
  • pokerdick123
  • dubem
  • oni
  • wizzy
  • atus
  • uzochi

Actor 02 (“OpSec”)

The next cluster we’ll take a look at also uses one server and, similar to the previous actor, the usernames take the format of e-mail addresses.

Figure 4. The “Opsec” cluster

Only one domain is used, nayyabgroup[.]com and, as the image above illustrates, each account uses a unique password. For this particular actor, the complexity of their FTP passwords was a good linking indicator, as it deviates from what is seen throughout most of the embedded credentials captured during this analysis.

  • P!{Xwn{eEV$T
  • ?G34p}b);w
  • k*wsOH*P]!up
  • C7,5#dg4X1b?
  • QsvGK8H9XGJ8
  • 0gZ3I%dmpXi5

The passwords appear to be auto-generated by a tool and might successfully protect against brute force attempts or unauthorized access. While the actor’s password policy appears strong, he or she seems to be disregarding the fact that credentials are embedded in malware that employs plaintext transport mechanisms.

A final indicator to attribute to this actor is the usage of the local name “sirvor” followed by three numbers, for example “sirvor123” – there are four different variants of this across the 11 samples using the FTP server.

Top Indicators for Actor 02 “Opsec”:

  • 243.113[.]211
  • sirvor
  • nayyabgroup[.]com
  • P!{Xwn{eEV$T
  • ?G34p}b);w
  • k*wsOH*P]!up
  • C7,5#dg4X1b?
  • QsvGK8H9XGJ8
  • 0gZ3I%dmpXi5

Actor 03 (“LogAllTheThings”)

For the third cluster, we again have one FTP server being used by the actor to drop their data. However, one unique attribute about this cluster is that the actor is using three different key loggers across 46 samples to dump data here – HawkEye, iSpy (coupled with Galaxy Botkiller), and PredatorPain.

Figure 5. The “LogAllTheThings” cluster

This use of multiple different key loggers could be determined by looking at the file names being stored on the FTP server.

(HawkEye log – 23.229.206[.]201)

 

 

(iSpy log – 23.229.206[.]201)

 

 

(PredatorPain log – 23.229.206[.]201)

Each of the families has its own unique capabilities and, more importantly, different ways of morphing itself to avoid detection. It’s not surprising to see the usage of more than one type of keylogger by an actor, as actors constantly need to update and change tools to stay ahead of defenders.

At the top right of this cluster you’ll notice eight different accounts all share a common password, “pentium12345”.

Figure 6. Password reuse by multiple accounts

While there were very few unique passwords, all of the credentials identified for this actor used a numeric suffix of either “12345”, “1234”, “123”, or “@@123123”. Similarly, the usernames were again formatted as e-mail addresses and the domain portions were all listed as“@bigcountrywater[.]com”, with seven of the 13 total accounts using “office” somewhere in the local portion. Tying these all together provides a strong indicator to identify this actor.

Top Indicators Actor 03 “LogAllTheThings”:

  • 229.206[.]201
  • pentium12345
  • bigcountrywater[.]com
  • @@123123

Actor 04 (“MailMan”)

Our last cluster in the top left was purely SMTP traffic to the e-mail server at “web.arch[.]ai”, used for transferring HawkEye logged data.

Figure 7. The “MailMan” cluster

As evidenced by the image above, almost every account had a unique username and password. Across the majority of the accounts identified, the passwords were structured to take part of the username (e-mail format) and suffix it with five numbers, usually “12345” or “54321”. For example, if the username was “username@email.com”, the password might be “user54321”, which provided a consistent indicator across the 45 samples identified.

In addition, out of the 20 unique accounts identified sending data to this e-mail server, only two domains in the username field were seen during this analysis, “shamaraholdinq[.]com” and “pmtlogisticsinc.co[.]uk”. A quick WHOIS search for these domains shows the same registrant, based out of Nigeria, with a number of other domains registered that can be used for further pivoting and analysis.

Figure 8. The man behind the mail

Looking at the domains, you can guess the type of phishing activities being carried out by this actor.

Figure 9. Masquerading as US Government sites

Top Indicators Actor 04 “MailMan”:

  • web.arch[.]ai
  • shamaraholdinq[.]com
  • pmtlogisticsinc.co[.]uk
  • Nelson12345
  • abacom12345
  • abuchi12345
  • abuchi54321
  • alfred54321
  • bethel54321
  • bro54321
  • compu54321
  • ebuka12345
  • humble12345
  • immortal12345
  • kaycelaz5
  • kelechi12345
  • kunde54321
  • miraclebaby16
  • obi12345
  • opera54321
  • philip54321
  • shoki54321
  • spencer098765
  • sular54321
  • sular@54321

Conclusion

In the grand scheme of keylogger activity, this was a small sample set. Despite this, it was enough to highlight that using embedded credentials at scale could be leveraged to gain insight into actor behavior and infrastructure. It’s a practical technique and quickly identified at least four different actors actively utilizing keyloggers to steal data from compromised systems.

It should be obvious, but it’s worth stating: keyloggers aren’t going anywhere and without a doubt they will only continue to evolve like every other type of malware. As this happens and we’re left trying to protect our organizations, sometimes we can get lost in the analysis of minute details between various malware families, so it helps to change perspective now and again and take more of a macro look at the landscape in front of you.

There is always a human element to these threats and, as evidenced throughout this blog and countless others, the people behind these threats can fall prey to the same issues that organizations do – poor operational security.

Palo Alto Networks customers are protected by these various threats through WildFire AV signatures. AutoFocus customers can further research these threats through the below tags.

AutoFocus Tag – iSpy Software
AutoFocus Tag – PredatorPain/HawkEye
AutoFocus Tag – KeyBase

Below are additional indicators from the discussed sample set, including the ones shown above, that were observed by the malware. Please note that individually, these indicators may not be enough to determine whether something is good or bad, but the combination of multiple indicators can lead to actionable intelligence. Account names will not be included in an effort to prevent any potential abuse from the credential pairs.

IP/Domains:

  • 107.180.44[.]128
  • 107.180.57[.]26
  • 108.179.196[.]24
  • 109.234.36[.]216
  • 134.255.221[.]14
  • 136.243.113[.]211
  • 142.54.182[.]66
  • 144.76.222[.]41
  • 176.9.193[.]213
  • 185.26.122[.]38
  • 185.28.20[.]80
  • 188.40.207[.]191
  • 192.138.189[.]30
  • 192.185.143[.]215
  • 198.58.93[.]56
  • 204.236.238[.]164
  • 208.86.156[.]40
  • 217.149.52[.]111
  • 23.229.206[.]201
  • 31.170.165[.]170
  • 31.177.95[.]21
  • 5.153.10[.]228
  • 50.87.151[.]103
  • 54.228.213[.]93
  • 64.20.39[.]210
  • 66.7.201[.]36
  • 68.171.217[.]250
  • 69.27.174[.]4
  • 69.30.206[.]114
  • 75.101.155[.]12
  • 81.95.158[.]149
  • 93.189.45[.]35
  • dallas125.mysitehosted[.]com
  • md-in-15.webhostbox[.]net
  • s2.dedicatedpanel[.]net
  • web.arch[.]ai
  • shamaraholdinq[.]com
  • pmtlogisticsinc.co[.]uk
  • adaata[.]com
  • affilor[.]org
  • al-nebaa[.]net
  • alexendriaairlines[.]com
  • american-petroleum[.]us
  • americanmilitary[.]co
  • armydepartment[.]us
  • armydept[.]us
  • atozcourierservices[.]com
  • aviatoncapital[.]com
  • ciafleasinq[.]com
  • conoilng[.]com
  • defencecourierservice[.]com
  • defensecourierdelivery[.]org
  • defensecourierservice[.]com
  • duluxsecuritiesinc[.]com
  • edfenergy[.]us
  • fasttrackexpressdelivery[.]us
  • fbideptinvestigate[.]us
  • fcmbservices[.]com
  • felixairvvays[.]com
  • fifaregionalprojects[.]org
  • firstrepublicbkc[.]org
  • g-t-b-online[.]com
  • gaffrey-kroese[.]com
  • gcb-gh[.]com
  • gcb-gh[.]net
  • gcb-ghana[.]com
  • gcb-info[.]com
  • gh-consultant[.]com
  • ghobashco[.]com
  • horizons-us[.]com
  • hsbc-onlineservices[.]com
  • information-ny[.]com
  • investigateinterpol[.]net
  • librarytech[.]net
  • maincentralbnk[.]com
  • memconpjo[.]com
  • nawesservices[.]com
  • nicemachs[.]com
  • nigeria-custom[.]com
  • otizjo[.]com
  • pacificliife[.]com
  • pannoceanic[.]com
  • petronas-malaysia[.]com
  • qirnemhemrinco[.]com
  • qtps-inc[.]com
  • satanderonlineservices[.]com
  • sonozcape[.]net
  • standardbnkforex-za[.]com
  • techenica[.]com
  • tsa-bwi[.]com
  • ubacare[.]com
  • unfraudunit[.]com
  • unpf[.]us
  • usamilitarydept[.]us
  • usaphysicist[.]us
  • ushomeland-security[.]us
  • zs-dds[.]com

Passwords:

  • 0Withgod1
  • 0gZ3I%dmpXi5
  • 238Wmi9cnJ
  • 4Z*~uigF{mKD
  • 92z7nyy6CU
  • A.?G34p}b);w
  • ADmin7455&
  • ATIba2001!
  • C7,5#dg4X1b?
  • Chimaeze12
  • Confirmed1
  • F:SBrjW1
  • General123#
  • H;cLNBkHKO&g
  • Kunde54321
  • LAURINA12
  • Nelson12345
  • P!{Xwn{eEV$T
  • Pwd123456@@123
  • QsvGK8H9XGJ8
  • Team2318@
  • Unbekannt88_$(98)
  • Waly1981
  • ZzZ_#C0FA)^#
  • ^al3M@1cr.eW
  • a4def60f
  • abacom12345
  • abuchi12345
  • abuchi54321
  • accounts1961
  • alfred54321
  • bathram0123
  • bethel54321
  • bro54321
  • chibueze54321
  • chimaeze12
  • codin1234
  • compu54321
  • dogood11
  • duracellgrief
  • ebuka12345
  • humble12345
  • immortal12345
  • joinkrama2
  • js123!
  • k*wsOH*P]!up
  • kaluojuotta1234
  • kaycelaz5
  • kelechi12345
  • kunde54321
  • loco1234
  • miraclebaby16
  • nathaniel
  • nathaniel45
  • nde10wp10
  • nineslips09
  • obi12345
  • odichigo54321
  • opera54321
  • owerrisouth
  • pentium12345
  • pereyikelamo2
  • philip54321
  • pokerdick123
  • pwd12345
  • shoki54321
  • spencer098765
  • sular54321
  • sular@54321
  • team2318
  • victory45
  • wp@@123123
  • xpen2000

[Palo Alto Networks Research Center]

Posted on

2016 (ISC)2 Security Congress General Session to Focus on CISO Impact

Chief information security officers and their teams must lead their organizations into adopting safe business practices. In our increasingly connected world, this goal is more important than ever. Speaking the language of the C-suite and the board, and translating information security into business terms is key for CISO success.

The General Session at this year’s (ISC)² Security Congress will help CISOs chart their paths to successful leadership and cybersecurity practices. “CISO Impact: Driving Security Into the Business” will be presented by Phil Gardner and Stan Dolberg. Both speakers are executives at IANS, an information security advisory and consulting firm: Gardner is founder and chief executive officer, and Dolberg is chief research officer.

The session is based on IANS’s data-driven leadership framework, CISO ImpactTM, based on research with more than 1,000 information security teams, including many (ISC)2 members. The session will take place on Thursday, September 15 from 8:00-9:00 a.m.

Gardner founded IANS in 2001 and currently oversees strategic and operational decisions. He has seven years of service in security with the U.S. Navy as a strike fighter pilot and ordnance requirements officer. He received his B.A. from Harvard University, as well as his MBA from Harvard Business School.

Dolberg has been the chief research officer at IANS since 2015. Before joining the organization, he ran his own consulting firm working with CEOs and boards of technology companies, addressing key questions about markets that affect sales velocity. He received his B.A. from Harvard University and his MBA from the Carroll Graduate School of Management at Boston College.

Along with the General Session, full-conference attendees will have access to more than 90 educational sessions, as well as the exhibit floor, Career Pavilion, and Solutions Theater. This year’s Security Congress event has 11 tracks:

  • Application Security/Software Assurance
  • Cloud Security
  • Forensics
  • Governance, Regulation and Compliance
  • Incident Response
  • Malware
  • Mobile
  • People Centric Security
  • Professional Development
  • Swiss Army Knife
  • Threats: Inside & Out
  • Threat Intelligence

While the first session takes place Monday morning, September 12, (ISC)2 members are invited to attend the annual Town Hall meeting the day before, Sunday, September 11. (ISC)2 leadership, including CEO David Shearer and board members, will be available to answer questions about membership, certifications and more. Questions may be submitted to the panel via email at congress@isc2.org or tweet them to us on Twitter @ISC2Congress (Use #Congress16TownHall).

This year’s (ISC)2 Security Congress will take place in Orlando, Florida at the Orange County Convention Center from September 12-15, 2016. The event will be co-located with the ASIS International 62nd Annual Seminar and Exhibits, once again bringing together operational security and cybersecurity professionals. As the best-value and largest industry event of the year, more than 20,000 professionals from around the world are expected to attend. For more information, or to register to attend, please visit http://congress.isc2.org/.

[(ISC)² Blog]

Posted on

SDN Concerns and Benefits

Software-defined networking (SDN) is the next big focus in network intelligence. When the network is virtualized into the software-driven layer, the operations become more automated with less administrative overhead, allowing administrators to deeply penetrate the network fabric, giving better control through the programming ability in addition to reducing cost. However, as enterprises look to adopt  SDN, the top issue is the concern for security. As with any software and interconnected system, whenever we shift the responsibility of day-to-day activities and operations to a programmable software, we also invariably introduce an element of risk. Whenever resources are available over a network, there is always a chance of them being compromised.

Whether the use of SDN takes the role of being a straightforward standards-based SDN solution or proprietary technology from a single vendor, the fact is that all SDN technologies create the same problem for organizations:  Organizations are forced to trust and depend on software that is new, relatively complicated and not fully understood. Although the positives of SDN are well known and widely discussed, the negative impact of it being exploited is still a black box. For example, what are the SDN vulnerabilities of which the organization must be aware? Do these vulnerabilities take different forms in the control layer as compared to the data layer? What do an SDN rootkit or man-in-the-middle attack look like? Does an SDN worm have a different DNA  structure, making it harder to be identified than a traditional worm? The problem with SDN is that each control point on the network becomes a potential target of attack. If weak, it can be converted into an entry point for attackers who can further conceal these golden gates and cover them up from detection from monitoring and management watchdogs.

It should also be noted that with new generation technologies overhauling the traditional network setup, the organization’s operational support systems (OSS) becomes more dependent on automation and software. Humans could face challenges in identifying network security issues with the use of the SDN fabric on the network.

The future of SDN is promising with its obvious business benefits. In the early days of application programming, however, security was not given enough attention to ensure that it was embedded in each line of code and reflected in the architecture and design of applications. The impact of this misstep is still seen by the industry today. Organizations can only try to anticipate what the attackers may target with SDN. The implementation of SDN, its protocols and the controller programming software are all new, and our knowledge on SDN attacks is limited. Before an organization embarks on an SDN deployment effort, the key will be how it will strategize in securing the system during the early design stage and continue to implement strategies and processes around it based on the growing knowledge of the vulnerabilities around the use of SDN.

Read Nikesh Dubey’s recent Journal article:
“From Static Networks to Software-driven Networks—An Evolution in Process,” ISACA Journal, volume 4, 2016.

Nikesh Dubey, CISA, CISM, CRISC, CCISO, CISSP

[ISACA Journal Author Blog]

Posted on

An In-House Security Approach for Cloud Services That Won’t Drive Your IT Department Insane

“If your security sucks now, you’ll be pleasantly surprised by the lack of change when you move to cloud.” — Chris Hoff, Former CTO of Security, Jupiter Networks

The chances are, almost everyone in your organization loves the convenience of the cloud for data storage and for collaborative workflow needs. And why wouldn’t they when documents and files are now easily accessible to all team members, whether down the hall, in another state or even on another continent? From a cost and operations perspective, cloud storage is certainly pretty compelling. However “almost everyone” might not include CIOs, CISOs and their teams, who often harbor concerns about the security of data in the cloud, and particularly where sensitive data is involved. I have similar misgivings. I’m not saying that we should not use the cloud, but I do believe that we can improve how we secure sensitive data stored on it.

Blue Skies or Dark Clouds Ahead?
In a recent report titled “Blue Skies Ahead? The State of Cloud Adoption,” Intel Security said that IT decision makers are warming to the cloud along with the rest of us with 77 percent saying they trusted the cloud more than they did a year ago. This hides a darker reality that only 13 percent of respondents actually voiced full trust in the public cloud, with 37 percent trusting their private cloud. Surprisingly, a full 40 percent of respondents claim to process sensitive data in the cloud, indicating that there is both room and a real need for cloud security improvement.

Adding Peace of Mind to Cloud Storage
When I hand over data to a third party, I want to be sure that they are not only contractually obliged to look after it properly but are actually equipped to do it. This means protecting it from accidental loss, malicious attacks and from silent subpoenas, among other threats. Logging and multi-factor authentication are part of the tool kit that can be implemented, as is encryption. There is an existing (and growing) awareness of the importance of encryption which is why most cloud service providers offer encryption options of one kind or another. But too frequently the third-party vendor is doing the encrypting, and holding the keys, which isn’t very reassuring to say the least.

Fundamentally, the best way to ensure data is safe and managed well is to pre-encrypt it before it’s sent to the cloud. Coupled with a policy of keeping key management in house, these precautions should allow for several hours of blissful sleep each night for members of the IT security team whether the cloud is public, private, or a hybrid of the two! Other approaches include using 2 or more different vendors to handle the different parts of the storage solution: one vendor can manage the keys while the other manages storage itself. Key wrapping is another way to reduce risk: the end customer can manage master keys that in turn wrap the document keys, giving you some assurance of isolation between your data and that of other customers stored on the same cloud, as well as control for document access. Through these approaches, you can provide a significantly higher level of protection for data stored in the cloud.

Encryption is the best tool we have for protecting sensitive information so we need to use it to support and enable our expansion to the cloud. As seen above, the devil is in the details of how we do it, but keeping control of keys is fundamental. Of course, there is also the issue of how strong the keys are that you are using, but that is a topic for another day….

Jane Melia, VP/Strategic Business Development, QuintessenceLabs

[Cloud Security Alliance Blog]

English
English
Exit mobile version