Systems Engineering Life

When it comes to firewall upgrades or refreshes, you need to know your: Current traffic volumes and mixture Session counts Number of users Current and future Internet or private connection pipes Current and future throughput requirements (VPN, SSL Inspection and decryption, etc...) Current and future unified threat management (UTM) needs Interface requirements  Number of IP devices LAG requirements  Future growth  I am sure you can come up with more variables and compare it to the vendors specification sheet in order to come up with an accurate size or model of a security appliance.  However, nothing beats a real/live test with a traffic generator.   When I usually size a box based on the customer's requirements, I also factor in real life examples, previous firewall implementations and what the Internet/application traffic trends. I have heard so many "oh we are not going to use such and such application" or "we will never use SSL inspection"...

Does your product integrate with other security products? At this point, you should hate product silos (point products) as much as I do.   I understand and respect “divide and conquer” or “best of breed” strategies. I also understand having different security vendors at different layers of the network could possibly prevent an incident better (one vendor might not see/catch a vulnerability but another might have a signature or way of catching it). But isn’t it time to ask your vendors how and if they can work with each other? So what we (vendors) are competitors?   If by integrating with each other, we are able to increase the return on investment (ROI) for the customer, then why not (I know it might sound naive and unaware, but could you just imagine ). Vendors have application programming interfaces (APIs) for interaction with other platforms.   However, customers have to have application development resources to write code for these APIs, and that's not answ...

Your vendors’ systems or sales engineers are a wealth of knowledge.  I don’t say that because I am one, I say that because we have been around various IT departments as employees or sales engineers.  We have seen different ways of achieving the same goals and can save you headaches or hidden roadblocks. It is mostly a myth that we only know the technology we are representing or selling.   First of all, we have to know our competitors’ technologies well enough to be able to differentiate ours. Second of all, we have to know enterprise IT applications well enough to make sure our products actually work in tandem. SEs also talk amongst themselves.   I might not know the project you are working on, but I am sure one of my colleagues do.   I work with a great group of engineers from different backgrounds.   They are sharp and always willing to help. I’ve worked in energy (both upstream and downstream) industry, healthcare (distribution and provide...

Background: I have a number of customers in the retail industry.  Usually, they have a large number of remote locations (restaurants, brick and mortar stores, and kiosks). Before the cheap/high-speed Internet connections being used for enterprise connectivity (IPsec tunnels over these connections) and before the SD-WAN revolution, all of these remote locations’ traffic traversed private connections such as MPLS or frame relay connections to one or two centralized data centers to reach corporate resources or the Internet. Securing these types of set up were rather less complicated because you had one or two centralized points to secure (mostly at the edge where Internet was accessed). We are now faced with every remote location acting as an “Internet PoP” (point-of-presence).  These locations will use an IPsec tunnel over the Internet connection to reach corporate resources.  The Internet traffic is locally routed using their existing high speed connection but wit...

About me: I love books, specially history books, biographies and autobiographies.  I love learning from other people's experiences, struggles, shortcomings and success. Career History: I have been a pre-sales systems engineer (SE) since September of 2010 after working in various industry's IT departments as a network/security engineer. ( My LinkedIn profile ) I was introduced rather late to "Great Demo!" by Peter E. Cohen .   James Cabe who is one of the smartest people I know recommended this book at my on boarding at Fortinet. I think it is essential to learn the principles of pre-sales engineering and what a "real demonstration" is before even getting in front of customers. Now, the book talk about software demonstrations but I think it applies to any technical pre-sales engagement and demonstration. My good friend and colleague Eric Hastings  came up with an idea of standardizing and streamlining our demonstrations, proof of concepts and pilot...