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]

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]

Tech Docs: Simplify Policy Management Using a Panorama Device Group Hierarchy

How Do Device Groups Help Me Manage Policy Rules?

Device groups make configuring firewalls easy by enabling you to group firewalls that require similar policy rules based on location and function. You can make your configuration workflow even easier by nesting device groups in a hierarchy with the predefined Shared location in the top layer and then parent and child device groups in descending layers. In a device group hierarchy, all firewalls inherit rules and objects that are common across your organization from Shared and the firewalls in child device groups inherit rules and objects from parent device groups. Inheritance enables you to avoid configuring duplicate settings in each device group.

How Do I Configure a Panorama Device Group Hierarchy?

Say you have data center firewalls in Chicago and Cairo and branch office firewalls in London and Shanghai. To avoid redundant configuration, you can create six device groups, each containing only the settings that are specific to the firewalls used for each function (data centers or branch offices) or each location (Chicago, Cairo, London, or Shanghai). Configuring the Chicago and Cairo device groups as children of the Data Center device group ensures that the firewalls in those locations inherit the Data Center settings. Similarly, configuring the London and Shanghai device groups as children of the Branch Office device group ensures that the firewalls in those locations inherit the Branch Office settings. All the firewalls in every location inherit shared settings.

(Click to view downloadable PDF.)

For detailed instructions, refer to Create a Device Group Hierarchy in the PAN-OS 7.1 Administrator’s Guide.

[Palo Alto Networks Research Center]

Next-Gen Drive: Robert Megennis Only Rookie (and American) in Top 10!

Robert Megennis is a 16-year-old racing prodigy. Palo Alto Networks is proud to be an ongoing sponsor of Rob’s races for the 2016 Mazda Road to Indy racing season. We’ll be checking in tochronicle his adventures as a true next-generation competitor!

After nine races, including the recent Grand Prix Road America in Wisconsin, Rob is the highest ranked rookie in the championship, with almost double the points of the next closest first-year driver. He is the only rookie in the top 10, and the only American in the top 10. On to Toronto!

Check out photos from Rob’s recent travels and fan feedback below.

“We both wanted to thank you so much for the wonderful hospitality and also the amazing view and great food yesterday. Rob is such a great kid–we can’t wait to keep following his career! We will wear the t-shirts with pride!”

“Thanks for the inside look at racing. We enjoyed it a lot. Best of luck to you, Rob, and the whole team this year!”

[Palo Alto Networks Research Center]

Training, Awareness Keys to Battling Social Engineering

The weakest link in every security posture is always the human element, which is a problem because the core asset of every business is its people. It is that human factor that makes social engineering such a significant, difficult to manage problem.

The term “social engineering” incorporates any and all human-intelligent interactions that are designed to elicit an involuntary or unconscious response that serves the social engineer’s need. In many cases, this means that social engineering is conducted to elicit sensitive/private information or induce end users or enterprises to adopt a certain set of behaviors.

Typically, social engineering is a precursor to, or simultaneous to, technology-based attacks. The overall attack, therefore, has a technical and a social component, allowing attackers to fine-tune their methods and reactions to end-user or corporate behavior. The more background research and intelligence the social engineer possesses, the more difficult it will be to recognize the social engineering attempt.

Social engineering is especially dangerous for employees who may have special access to valuable assets that other employees may not, such as the ability to wire funds. A good example of this occurred last year when Ubiquiti Networks Inc., a US-based manufacturer of high-performance networking technology for service providers and enterprises, was taken for US $39 million. An employee of a Ubiquiti subsidiary was the victim of a CEO scam, which hijacks or impersonates the email of a senior executive within an organization. In this case the victim, who had authority to initiate wire transfers, transferred large amounts of money from company accounts to the criminal’s accounts.

Adversaries are cognizant of the basic human tendency to trust people on face value, and accordingly, they abuse that trust to perform social engineering attacks. Unfortunately, the best way to combat these conditions is to change behavior. Specifically, it is best to change behavior in a way that makes people less trusting and more skeptical. Changing behavior is already difficult and especially more so when the change requires a person to acquire a bleaker outlook on the world around them. For these reasons, organizations need to recognize that results may require investments of time and resources to drive a long term change.

Increasing Vigilance, Awareness
It takes considerable training and awareness for organizations to develop the skills and collective mindfulness required to consistently fend off social engineering attacks. Though commonly seen as synonyms, it is important to note that training and awareness are distinct topics.

Training seeks to educate individuals about what they should or should not do. Through training, personnel become more educated about the ways they may unwittingly become victimized, so they can become more vigilant. For example, a good training program would teach attendees about why they should be suspicious of a phone call asking for information, and it would provide them with techniques to politely ascertain the validity of the request.

Awareness seeks to galvanize the group to address security problems together. Through awareness, members of a team become more cognizant of what each member is doing. For example, an effective awareness program leads members to raise a red flag if they see a delivery person walking through the office area unescorted. Seemingly innocuous circumstances (such as package deliveries) are the arenas in which social engineers operate most effectively.

Editor’s note:  ISACA Now is running a series of blogs on the 10 threats covered in ISACA’s Cybersecurity Nexus (CSX)Threats & Controls tool.  To learn more about the controls for cybercrime, as well as recent examples and references, typical patterns of cybercrime and more, visit the tool here. Ted Harrington drives thought leadership initiatives for Independent Security Evaluators, and is a sought-after speaker, presenting at high-profile conferences in a range of industries, including media and entertainment, hospitality, finance and others.

Ted Harrington, Executive Partner, Independent Security Evaluators

[ISACA Now Blog]

English
Exit mobile version