President Obama is taking the US government mobile.
Recently, the President issued an executive order memorandum to his department and agency heads calling on them to embrace mobile technology to deliver more data, more efficiently. The order requests agencies to follow a new technology strategy called the “Digital Government: Building a 21st Century Platform to Better Serve the American People,” which includes the request for a road-map for responding to the technology transformations of Bring Your Own Device (BYOD) and mobile device proliferation.
Many organizations are already embracing mobile devices with over 95% of them allowing employee-owned mobile devices in some way, shape or form in the workplace according to recent research sponsored by Cisco. Not only do we expect our employers to allow us to use our personal devices, we want to gain access to new products and services—from the private and public sector organizations. So, yes Mr. President, “Americans deserve a government that works for them anytime, anywhere, and on any device,” And --nice timing on this order, welcome to Silicon Valley-high tech land—I saw you fly in two week ago from the Saratoga hills!
Cisco shares this same sentiment of allowing people to use any device their way without compromising the organization. Cisco announced their answer to the BYOD (bring your own device)—with BYOD Smart Solution which starts with Cisco validated designs and professional services that can guide you from planning and design through day-to-day operations. It combines array of products starting with the core tenants of access points, security, controllers and network management. To address a key concern of the mobile experience, security, Cisco uniquely offers unified policy for secure access -- Identity Services Engine (ISE) and next generation remote access, AnyConnect—for always on secure remote access. And most recently, Cisco also spoke to a “Your Way” mobile experience which includes the core components and then some –which allows for more efficiencies and collaboration resulting in more productivity. Mr. President and US citizens this is very achievable!
Citizens of US –I would like to hear your thoughts on gaining Federal services from your mobile device –which services would be a priority for you? Why? Do you have any concerns? What is your number one concern?
Tags: access, byod, government, mobile, mobile devices, Obama, President, security, White House
There are a growing number of large-scale IPv6 deployments occurring within enterprise, university, and government networks. For these networks to succeed, it is important that the IPv6 deployments are secure and the quality of service (QoS) must rival the existing IPv4 infrastructure. An important security aspect to consider is the local links (Layer 2). Traditional Layer 2 security differs between IPv4 and IPv6 because instead of using ARP—like IPv4—IPv6 moves the traditional Layer 2 operations to Layer 3 using various ICMP messages
IPv6 introduces a new set of technology link operations paradigms that differ significantly from IPv4. The changes include more end nodes that are permitted on the link (up to 2^64) and increased neighbor cache size on end nodes and the default router, which creates more opportunities for denial of service (DoS) attacks. There are also additional threats to consider in IPv6 including threats with the protocols in use, a couple of which are listed below:
- Neighbor Discovery Protocol (NDP) integrates all link operations that determine address assignment, router discovery, and associated tasks.
- Dynamic Host Configuration Protocol (DHCP) can have a lesser role in address assignment compared to IPv4.
Finally, non-centralized address assignment in IPv6 can create challenges for controlling address misuse by malicious hosts.
For more information on FHS concerns. read the new IPv6 FHS whitepaper.
Tags: first hop security, IPv6, IPv6-security, security
Share your knowledge by taking the 5-minute Cisco Regulatory and Industry Compliance Survey
Greetings from Cisco’s Compliance Solutions team!
Over the past several years, we have developed an architectural approach to achieving and maintaining regulatory and industry compliance. Our latest work provides – in great detail – both a framework for achieving PCI DSS compliance and recommendations about how to make your Cisco-based network PCI compliant.
To address the topic with authority, we integrated Cisco and technology partner products together into a comprehensive solution based on foundational Cisco architectures, had a QSA auditor – Verizon Business – assess it for PCI DSS 2.0 compliance, and documented the results in a publicly-available Design and Implementation Guide which can be found here: www.cisco.com/go/pci
Our team’s broader vision is to enable Cisco customers to manage risk by achieving and maintaining compliance with a broad range of regulatory and industry mandates. We believe that
- Your challenges around compliance are growing and that you are looking for sound guidance as you work to achieve and maintain compliance with multiple mandates;
- The value we deliver starts with a thoughtfully-developed architectural framework but also includes a broad array of Cisco and partner technology that has been tested and assessed by third party auditors;
- Integrated and proven compliance solutions will give you confidence in Cisco’s ability to act as the foundation for achieving and maintaining compliance.
Looking forward, we plan to engage in conversations with our readers. You will hear from the team regularly on a variety of topics and we’ll ask about your views as they relate to compliance. Your thoughtful responses will help guide our future work.
In that spirit, we are very interested in your thoughts right now! We developed the “2012 Cisco Regulatory and Industry Compliance Survey” which can be found at:
The survey is anonymous and it will take about 5 minutes to complete. In future blog posts, we will share the results with you.
Thanks in advance for your contribution.
Cisco Compliance Solutions Group
Tags: Cisco, compliance, pci, PCI Compliance, pci-dss
This post is a continuation of The Missing Manual: CVRF 1.1 Part 1 of 2.
Praxis: Converting an existing document to CVRF
Now it’s time for some XML! Let’s take what you’ve learned and manually convert the Cisco RVS4000 and WRVS4400N Web Management Interface Vulnerabilities security advisory into a CVRF document. Please note that this process is meant to be instructive and somewhat of a stream-of-consciousness-narrative of how to manually build your first CVRF document. It is expected that, by and large, this process would itself be automated and CVRF document producers would have in-house code to parse their own documents and emit CVRF.
Read More »
Tags: automation, cvrf, intelligent automation, security, security advisories
In this post you will learn about some of the design decisions behind the 1.1 release of the Common Vulnerability Reporting Framework (CVRF). Particular attention is paid to explaining some of the required elements and the Product Tree. After those tasty tidbits, we will convert a recent Cisco security advisory into a well-formed and valid CVRF document. To close, you are treated to some of the items on the docket for future versions of CVRF. It bears mentioning that this paper is not meant to be an exhaustive explanation of the CVRF schemata. It is a rather capricious, if somewhat disorganized look at some outliers that aren’t fully explained elsewhere. It is assumed the reader has a working knowledge of the Common Vulnerability Reporting Framework and of XML.
Tags: cvrf, security, security automation