A Reference for all Cisco UC and Security Professionals and Decision Makers

It’s always meddling when those pesky questions around design or deployment of a UC network’s security are raised. More often than not one finds him/her (self) amid a flurry of queries.

Now, there’s a guide, a reference, and a companion to be with you always when there are queries around Cisco IP Telephony / UC security. You won’t be left alone when the discussion is around securing the UC applications or underlying network. Cisco Press publication ‘Securing Cisco IP Telephony Networks’ will be with you to address any and all queries pertinent to secure Cisco UC design approach or deployment strategy.

The book is available in paperback and eBook format:

Cisco Press



Posted by on November 3, 2012 in UC Security Posts


Tags: , , , , , , , , , , , , , , ,

Trying to get back on track – outside of 9-5!

And it’s been a while that I published anything on the blog. The major reason – I was shifting between continents from Asia to Australia. Well that’s one and other is I was also changing jobs as moving to a new country and settling in with family is never as easy when moving with kids and mrs.

All said and done, I’m trying to get back on track with works and blog posts. Things will become more seamless as months progress.

Moving forward my posts won’t just be around security however, more around holistic with virtualization, automation, orchestration included.

More to come in this space. Keep an eye out.


Leave a comment

Posted by on September 8, 2019 in UC Security Posts


PCI-DSS Compliance in the Cloud – Top five recommendations to ensure smooth sailing

PCI-DSS (Payment Card Industry Data Security Standard) is a norm, a standard for any organization involved with card transactions and storing card data. I won’t be going to rudiments of PCI-DSS as these are well covered in many articles across the Internet. The whole idea of this post is to understand the key considerations for implementing PCI-DSS in public cloud.

Here are top five recommendations from my experience with implementing cloud ecosystems for financial institutions. These are based on PCI-DSS v3.2

Recommendation 1: Restrict AccessJust IAM isn’t enough, segmentation is the key.

PCI compliance requirements entail that the access to key data and data storage systems is limited. The access can be limited/restricted by using IAM. As leading practice. segment your production and test, QA, or development environments. Prevention is the key and by segmentation you can ensure that no unintended audience gets access when segmentation (VPC or VNET based) is augmented by the IAM controls. It’s really important to make sure that your IAM user policies allow users in your environment only to do what they need to do.

Recommendation 2: Leverage more than Native Cloud SecurityMultiple VPC/VNET based segmentation complemented by ISVs for advanced security controls.

PCI-DSS requires that card holder data is secured. The best way is to have this data in your private subnet(s) that isn’t directly accessible from the Internet. The combination of security group policies and network access control list is an effective way to ensure only traffic that’s intended to get in or out, get’s in or out. Additionally, leveraging advance security controls is beneficial to get more visibility inside the cloud. For example, deploying ISV firewalls at perimeter of VPCs/VNETs can give a lot of threat and DLP protection that cloud native security doesn’t offer. Moreover, the logs from ISV offered firewalls can be used for threat monitoring as well as incident response.

Recommendation 3: Encrypt Data in Transit Data security is paramount, even more so in transit.

Data in transit is most susceptible to attacks from within and outside an organization. An absolute requirement is to encrypt your data using VPN (site-to-site) or with SSL/TLS. Make sure that the cipher suite only allows secure ciphers for example – do not allow SSLv1.0 in the list of ciphers. Also, it is important to understand where to terminate the incoming SSL streams i.e. at ELB or at web servers. While it depends on environment to environment on where the SSL/TLS would be decrypted, a nominal schema could be if you have a large setup sitting behind external/elastic load-balancers, you can terminate your SSL at the elastic load balancer. For a small subset of servers you can terminate it on servers. Again, the question of being able to look into encrypted streams by firewalls or threat-prevention systems would lead to one or the other decision.

Recommendation 4: Patching and Vulnerability ManagementBoth go hand in hand

Making changes first in staging environment and testing patches on a regular cadence helps avoid usual issues and pitfalls pertinent to vulnerability management. Patching doesn’t end up at operating system layer however, application patches also matter. Once, testing is completed, you can roll out patches to production during a maintenance window. For example, you come across a new POS software that needs to be patched and the application at the back end also needs patching. You won’t wait forever to patch these as, PCI-DSS 3.2 mandates the patches to be deployed outside of usual vulnerability management cycle as soon as an exploit is discovered; within a month. This is better known as prioritized approach. Besides patching, there’s vulnerability scanning of your web servers and other applications, which must be done on regular basis – to be more precise at least every six months unless there’s a change in any network configuration.

Recommendation 5: Secure Your System and AppsSecure Development is Key, Let’s not forget Logging

While developing applications in a PCI environment, it is common to follow top 10 project and guidelines from Open Web Application Security Project (OWASP). Secure development of code and deployment leveraging OWASP is a key not to get hacked (easily). Besides secure development, there are some nifty logging services offered by AWS and Azure to help secure your applications. For AWS, logging services for example – CloudTrail, ELB logging, and S3 logging helps identify the sources of changes in your cloud environment and offers audit trail. On the other hand, Activity Logs, Azure Diagnostic Logs, AAD Reporting, and Virtual Machine & Cloud Services are some of logging services offered by Azure.These services allows you to understand if and when changes are made to your environment and enable you to observe any discrepancies.

These by far, are not a comprehensive list of recommendations, security controls or services that may be used with your cloud implementation for PCI-DSS environments. This is just a small list of most viable and possibly critical services and controls that you would want to enable / deploy for your cloud setup.

Give a thumbs up if you like this article and if these recommendations are useful to you. Comments and feedback – most welcome.




Leave a comment

Posted by on June 24, 2018 in Clouds and More


Network Programmability and Automation – Reviewing was Fun and Learning!

In my last post on tech editing of Network Defense and Countermeasures , I shared that it was a refreshing experience tech editing a pure play security book.

I tech reviewed / edited a new cadre of book – Network programmability and automation late last year. This is the book by O’Reilly. I’ve reviewed a few reports earlier by O’Reilly however, this was first manuscript that I got to review so it was beyond just a few pages.

So, what’s different from other titles I reviewed? Simple, this book is all about automation and programmability of Networks to automate mundane tasks and let scripts do things for us. Yes, it is very different and while I have decent experience in using scripts with cloud platforms, it was also a learning opportunity with various languages and frameworks explained in the book. This is s good read for those trying to build up on automation and scripting side of things.

Here’s few glances of the book.

Look forward to do more automation with SDN platforms, public cloud and otherwise in upcoming months; of course alongside securing the unsecured.

Happy reading.


Network Defense and Countermeasures – Tech Edited!

The third edition of Network Defense and Countermeasures is out on shelf. And it was really fun tech editing it. The book is really comprehensive from basics to advance topics. It’s available on Amazon

I just got my copy in mail and it was exciting to see something printed (yes on real paper; not Kindle) with my name to it.

Yes, it’s a very refreshing change from looking at ebooks and such.

More to come in following months 🙂

Happy reading!

1 Comment

Posted by on April 27, 2018 in UC Security Posts


Hacks all the way – Yes, the Public Cloud isn’t Secure by DEFAULT!

Recent Uber and Tesla hacks have resurfaced the same question as last year – when Equifax was hacked.

“Is the cloud secure?”

One side of the coin says: Yes, the cloud is secure – when it’s about the infrastructure of the cloud provider. For one – if there’s an attack on AWS and Azure; they will defend their infrastructure from cyber attacks.

Other side of same coin says: No, the cloud isn’t secure – when it comes to cloud consumers; their workloads are their own responsibility per the shared responsibility model. AWS and Azure do not care if ‘your’ (the consumer) instances/VMs are under attack.

Still confused? Alright, here’s an example to set things straight.


You have two options when it comes to procure a laptop – buy upfront for about $1,500 or lease for $30 per month for 3 years. Now, obviously getting it upfront is $1,500 – ($30*3*12=) $1,080 = $420 more than leasing over 3 years.

So, leasing seems like a good idea. There’s however a catch. When you buy a laptop, you get an OS, some applications, may be antivirus and such. And, there’s may be warranty for some software alongside the warranty for hardware for next three years. However, in case of leasing the laptop  you don’t get anything but the bare-metal laptop. You have to install your own OS (of your choice – yay), and other applications such as office, antivirus, and such. However, you do get physical damage coverage all the same as upfront purchase.

** Now, hopefully that’s comfortably equitable to on-premise vs. cloud concept. You can build your DC and spin up VMs or, you can go and grab compute, storage and network from a cloud provider, and spin up VMs. Latter gives (potential) cost savings, (definite) agility and elasticity, and (absolute) lower Time To Market (TTM) as result of elasticity and agility available to IT and Dev Ops.

Now, one fine day – your own machine breaks down. What do you do? Call the helpline and get onsite or remote help! If it’s physical damage you get repairs done or if it’s a software issue you get software support.

And, in case you leased the laptop – you can only call the vendor for fixing hardware. Since, the laptop came with no software, any software on it is outside of vendor’s responsibility area.


Now, match this to on-premise vs. cloud. On premise – you build something and get software with support (more often than not unless you’re doing open source). On cloud however, you build your software instance (IaaS) atop the vendor offered compute, storage, and network. Now, if in latter case – your software / VM / Instance is breached; it’s none of the vendor’s concern to fix or even look into the matter.

Here’s AWS Shared Responsibility model at a glance:

Image result for aws shared responsibility model

And that for Azure is as follows:

Image result for azure shared responsibility model

So, all in all it is important to understand where the vendor responsibility towards security of ‘your’ valuable assests ends and where ‘yours’ starts.

Coming back to previous point, Uber could have stopped the hack by adopting appropriate security controls at various levels. First, not to allow any Github code to be downloaded. Second, prevent any malicious code to be executed (yes, ATP is useful). Third, not to allow the threat to travel within the cloud (East-West). And finally, to thwart any attempt to connect from compromised instances to the perpetrator of crime (there’s something known on lines of Anti Bot).

Please, do not forget that you were and still are responsible for security of what’s dear to you. Putting data on cloud and hoping for miraculous security will not bear fruits anytime. It’s a futile attempt to think that there’s security by default.

Leave a comment

Posted by on April 26, 2018 in Cyber Security


My CCIE 10th Year Anniversary Plaque

My CCIE 10th Year Anniversary Plaque

Today’s a special day. Just got my CCIE 10th Year Anniversary Plaque. In all it’s glory – shining like nothing has ever shined! 7th Dec 2007 was the day when I achieved my first CCIE and then in Feb 2009 the second one. Been a decade and still the memories of that era never fade; and for good.

CCIE 10th Year Anniversary

This plaque is something that reminds me of the grits and guts I put in 10 years ago. A sweet memoir of days when I used to slog day in and day out in preparation of my greatest personal battle – that of achieving the highly coveted CCIE title. It was my love, my life and I adored it not just once but twice – doing my Double CCIE.

“Nostalgia at its best!”

Proud and humble to be one of a few thousand CCIEs across the globe. Good to remember what I stood for and feels even better to keep doing what I love – my passion for technology and zest to learn has only grown with time.

Thank you dear god, my parents, my family and my friends for your love, support, and blessings.


Leave a comment

Posted by on February 2, 2018 in UC Security Posts


2017 – Year in Review and Looking Ahead from Cyber Security Standpoint

It’s been a while that I’ve posted however, it is because my new job and regional profile. I’ve been traveling a fair bit and being kept on the toes  🙂

Not keeping away from facts, 2017 was a year of (cyber)security incidents. From ransom ware for example  Petya to breaches at Equifax and Uber (and so many more), the year was pretty eventful from security perspective. Not just we witnessed big names getting breached and user data ex-filtrated, there was a mass momentum from bad guys to target and bring down key industry players in no time.

In response, security vendors were swift and came out with workarounds and fixes. Moreover, industry became aware of the fact (yet again) that humans are the weakest link in the scheme of cyber security. Vulnerabilities and exploits were introduced by virtue of weak security construct, policies, and configuration.

To sum it up – 2017 was an eventful year and a handful for security analysts and advisers alike. Looking forward – 2018 has had a big bang start with Meltdown and Spectre exploits. We’ll see how 2018 turns out from cyber security perspective however, I have a strong feeling it will be a step up as dark net continues to grow and flourish and the bad guys continue exploiting the connected systems.

Happy New Year to everyone!

Leave a comment

Posted by on January 14, 2018 in UC Security Posts