For the past 15 years, businesses of all types and sizes have used IP cameras to monitor and protect their physical environments. Whether monitored in real-time by security staff or analyzed following a breach, cameras provide an essential physical security solution to keep employees, data, and network appliances safe.
While this use case is still very much relevant today, the advent of the Internet of Things (IoT) has dramatically expanded the scope and capabilities of connected cameras now acting as powerful sensors and intelligent platforms to also deliver extraordinary gains in operational efficiency, situational and acoustic awareness, and forensic investigations. Furthermore, the evolution of video analytics such as facial and license plate recognition, as well as audio analytics, has significantly enhanced the ability of IoT-enabled cameras to deliver superior insights into all application areas – from safety and security, to business intelligence.
Read More »
Tags: Internet of Things World Forum, IoE, IoT, IoTWF, IP Video Surveillance Cameras, security
The HIPAA Omnibus Final Rule, released January 2013, goes into effect this month – Sept 23, 2013. Over the last several weeks, I’ve been posting a blog series around nine HIPAA network considerations.
- HIPAA Audits will continue
- The HIPAA Audit Protocol and NIST 800-66 are your best preparation
- Knowledge is a powerful weapon―know where your PHI is
- Ignorance is not bliss
- Risk Assessment drives your baseline
- Risk Management is continuous
- Security best practices are essential
- Breach discovery times: know your discovery tolerance
- Your business associate(s)must be tracked
This blog focuses on #6 – Risk Management is Continuous.
You can look at the Risk Management implementation specification as the actions taken in response to the Risk Assessment. The HIPAA Security Rule defines Risk management (Required): “Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with [§ 164.306(a)]”
(1) Ensure the confidentiality, integrity, and availability of all electronic protected health information the covered entity creates, receives, maintains, or transmits.
(2) Protect against any reasonably anticipated threats or hazards to the security or integrity of such information.
(3) Protect against any reasonably anticipated uses or disclosures of such information
One common mistake companies make in compliance programs is taking the approach that once the work is done, the network doesn’t have to be looked at again for compliance. If they put the security programs, processes, and technologies in place, they don’t have to spend time on compliance until next year (or the year after that, or even longer).
This makes compliance a onetime effort that is then ignored. Worse, securing PHI often follows the same path, making it easy to hack and steal, causing a lot of problems for everyone involved. Risk management―reducing risk―needs to be a continuous activity. Through your risk assessment, you’ll know where your PHI is, what your highest risk factors are, and where to implement more continuous risk management tools in the network.
Continuous risk management does not mean tracking every single event on every single device throughout the network. It may mean turning on automatic alerts on critical devices, setting traffic thresholds in network areas where PHI resides, logging anomalous events in those critical areas, and using network management tools to make sense of all this information the network devices are collecting.
Risk management is about a lot more than achieving HIPAA compliance, reducing risk to PHI and helping to prevent theft of PHI is of critical value.
Recommendation: Understand where you should implement continuous risk management, and what logging, alert, detection, and management tools you already have that can help with risk management.
To learn more about Cisco® compliance solutions and HIPAA services, please visit http://www.cisco.com/go/compliance
Tags: healthcare, HIPAA, PCI Compliance, security
Following my previous blog post about identity and device aware IT platforms making IT operations easier and more effective, I wanted to delve a little deeper into a specific element of the IT infrastructure: Security Event & Information Management (SIEM) and Threat Defense (TD) systems.
Read More »
Tags: event monitoring, ISE, security, SIEM
Our first SecureDC twitter chat created some great industry dialog around security for Software Defined Networks (SDN) as well as using SDN to improve security. SDN is going through a similar hype cycle as seen with cloud and we feel that it’s important to focus more on education now and broader collaboration, so that users can benefit from the tremendous potential SDN holds.
More Education, Less Buzz
We kicked off our conversation by asking what are the most pressing issues around SDN were. @Joltsik, Principal analyst at Enterprise Strategy Group, felt that users are confused with so much buzz, yet there’s little in the way of education.
@Raj_Samani, Chief Innovation Office at the Cloud Security Alliance and CTO at McAfee, went one step further indicating that greater transparency is also needed. However, @Jgreene3rd, Technical Lead for Data Center Security Technologies at Intel, noted that the upside of buzz is that it drives greater demand for availability, which in turn fuels education.
SDN and Improving Security
@KenSBeck, Principal Engineer at the Cisco Security Technology Group Office of the CTO, led an interesting discussion on how APIs for programming the network at network speed will allow security intelligence to be much more dynamic and eventually part of the network itself. @shl_eax_1, Technical Lead Engineer at Cisco Security Technology Group Office of the CTO, further noted how global visibility of the network hastens the speed with which security issues get resolved.
@fsmontenegro elaborated on how SDN security can enable more intelligent, granular and efficient response, and that SDN improves security by adding policy exceptions at the network layer with redirect flow. @vernonxt, SVP for ICT Research at IDC, honed in on SDN enabling better policy management. @AndiMann, Vice President at CA Technologies, speculated with automation enabling embedded policy and preventing random changes, shouldn’t SDN be able to do the same.
SDN Impact on Regulatory Compliance
@alokmittal65, Chief of Staff for the Cisco Security Technology Group Office of the CTO, stressed the need for auditing, logging and monitoring of policy change events.
@Raj_Samani also noted that with greater proliferation of devices, the ability to achieve greater attestation on the endpoint becomes more challenging. @KenSBeck drew attention to leveraging network awareness of user, geo location, and device as contextual elements that can make attestations much more meaningful.
@KenSBeck, our host from the Office of the CTO at Cisco, closed with words of advice and a hint of what is in store.
Keep the dialog going! Follow us on @Secdatacenter #SecureDC and join the conversation on LinkedIn Secure Datacenter Trends. For additional SDN resources, be sure to register today for our SDN Learning Seminars.
Tags: Cisco, data center, SDN, security
Detours is a library offered by Microsoft Research for interception of functions on x86 and x64 platforms. It is sold for commercial use to various vendors that build products ranging from security to gaming applications.
Detours is often injected into most or all of the processes, either system-wide or in the context of the logged in user. The most common way this is done is through the AppInit_Dlls registry value. Because the injection is typically applied to a large number of processes running under various permissions, extra care must be taken to ensure the library and its usage are very carefully reviewed by engineers with a strong understanding of the implications of such wide hooking.
We have used this library in our own security products at Cisco (both CSA and AnyConnect) to provide certain security functions on the system. During one of our research projects earlier this year, we noticed a peculiar pattern on Windows systems where processes we were hooking had a change in the in-memory permissions, which marked the headers of the modules from the normal READ/EXECUTE to now include WRITE as well.
This was quite alarming to us, because a dll should not be writeable when loaded into memory. What was interesting, and led to clues of what might be the cause, was that it was only the dlls that had functions we were actively trying to hook. They were the common Win32 dlls that one would typically intercept methods for, such as Kernel32.dll.
Read More »
Tags: DLLs, Dynamic Link Libraries, Microsoft, security, third party software