Description Mid-code Crisis http://www.tufin.com/blog/rss Tue, 04 June 2013 00:00:00 Tue, 04 June 2013 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2013/june/speed-up-the-“last-mile”-of-service-delivery/ What are you already doing to speed up your service delivery? Most organizations we talk to have already invested in automated configuration management and in DevOps solutions, but they are still experiencing delays in service delivery. For many of them, the bottlenecks occur at what is the "last mile" of service delivery: assuring that the network supports the new service. Nowadays, the "service" in service delivery is almost always an application. Having an application server setup and ready for production is futile if that server cannot access the database or the LDAP server due to a misconfigured router or a blocking firewall. Unfortunately, such scenarios occur all the time, and correcting the problem often turns out to be a time consuming and frustrating endeavor. Such delays have a direct impact on revenues as these network level requests support business-critical applications.  As networks become bigger and more complex, and organizations become even more dependent on applications, the last mile problem has gotten much worse.  And it will continue to do so until IT teams adjust their processes to account for the nature of the technology they become so reliant on. Because this is such a big problem for our customers, we've spent a lot of time talking with customers and researching specific points of failure. What we've learned is that application connectivity issues are by far the biggest reason for network change requests .   The problem is that application-related change requests are made by business owners who don't understand (or necessarily care) about the technical and security considerations of their change requests.  More often than not, requests are submitted with inaccurate or deficient technical data (such as a wrong IP address or a reference to a rule or object that no longer exists). By the time they are approved (if they are approved) and implemented (if they are implemented correctly), the business owner learns that they have to re-submit the request. Because this is an issue our customers grapple with daily, we decided to deal with it by developing automation, that  "understands" the connectivity demands of a new application, checks them against zone-based  security policies , automatically pushes them out to the network and maintains them over time (across all firewalls and routers). The fruit of our efforts: SecureApp. SecureApp is more than a point solution designed to speed up the last mile.  It enables network security teams to create and automate business processes that enable them to do their jobs. Check out this Forrester Study to see how SecureApp benefited one of our customers, SIX. SecureApp is still a new product - it is only eight months old.  If the economics of this report are any indication, we are connecting network security teams to the rest of the business in a much more significant way.   It has been incredibly exciting for me to play a part on bringing it to market, and I look forward to sharing our progress. Stay tuned..:-) http://www.tufin.com/blog/rss/blog/posts/2013/june/speed-up-the-“last-mile”-of-service-delivery/ http://www.tufin.com/blog/rss/blog/posts/2013/june/speed-up-the-“last-mile”-of-service-delivery/ Tue, 04 June 2013 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2013/may/the-firewall-has-been-tamed-and-now-the-fun-really-begins!/ At this year's RSA conference, we spoke with IT Harvest's Richard Stiennon to chat about innovations in the firewall market . Of all the meetings we had at the show, this was one of my favorites.  As Richard points, out, when it comes to firewalls, the old "moat and castle" model of perimeter security no longer applies.  Today's firewall management challenge is not to maintain a single enterprise perimeter, but to control access into and across countless network segments and ensure that the services running on those networks are available.  Control the flow of traffic and connectivity across those segments, and you control the flow of business. It's that simple.  With that being the case, it's a good thing we have "tamed the firewall."   But that is just the beginning.  Now that rule bases can be brought under control, we have set our sights on automating change processes.   If what we have done with customers such as SIX (which manages the network infrastructure for the Swiss Stock Exchange) and Kabel Deutschland (Germany's largest cable operator) is any indication, automating processes at the network level can accelerate the pace of business in meaningful way.   Watch the video to learn more about the changing role of firewalls http://www.tufin.com/blog/rss/blog/posts/2013/may/the-firewall-has-been-tamed-and-now-the-fun-really-begins!/ http://www.tufin.com/blog/rss/blog/posts/2013/may/the-firewall-has-been-tamed-and-now-the-fun-really-begins!/ Thu, 30 May 2013 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2013/may/network-abstraction-setting-the-stage-for-the-future-of-network-security-automation/ As networking and network security professionals, we are all faced with challenges.  While every company has its unique set of issues, if I had to categorize the main challenges our customers face, I would break them out this way: Complexity and Criticality: Networks have always been complex systems to manage, but nowadays networks have also become critical for delivering business solutions. Not only are these systems more complex, but companies are more reliant on them than ever. Limited Resources:  As the number of projects increases, the workload on network and security teams is constantly growing. At the same time, teams are often undergoing downsizing and outsourcing. Constant Change:  The reliance of business on IT, combined with the dynamic, competitive nature of modern business is accelerating the pace of change. Every day we process dozens of change requests to enable new access, new services and new applications that need to occur ASAP. Security, Risk & Compliance: While trusted to maintain a working network and deliver uninterrupted business services, network security teams are also required to protect corporate assets and reputation. This demands tighter and stricter means of control and compliance. These challenges, more often than not, present a tradeoff. You can't chink away at one without causing another one to spike.  For example:  You want to improve and tighten security and compliance controls? No problem. Increase the SLA - it will give the security team enough time to review every change request but it will also slow down the rate of change. Want to avoid the bottleneck? No problem. Hire more security engineers.  No budget? OK, just sample the rule bases rather than reviewing each and every rule. But a closer look reveals a common denominator to the problems above - they are all related to the computerization of business . The last decade has manifested an exponential growth of computerization which has forced businesses to rethink their IT architecture in order to keep up with the pace and remain competitive (see also "Consumerization"). While some aspects of IT have already been automated to cope with the accelerated pace of business, such as user management, server management and application release management, network change automation is still lagging. It is now time to implement network automation and to bring this IT silo up to speed with the other ones. But it in order to automate a network, some magic is required. Unlike servers and users which are mostly standalone items, networks are complex systems with a lot of interdependence.  An effective network automation solution, must take a holistic approach. It must be able to implement changes across multiple subnets and technologies from different vendors with minimal human intervention. It should also be able to take security factors into consideration and to deliver continuous compliance. At Tufin, we call this magic the "network abstraction layer" . It's a network model that includes routing, NAT, security policies, layer 2.5 configurations, virtualization, load balancing and more, all hidden away from an end user who can make a simple request: "allow these two systems to communicate with each other". A good network abstraction layer enables a computer to design network changes accurately and securely - this is the future of network automation. We all know there are no silver bullets. But we do have incremental wins, and the network abstraction layer is one that addresses each challenge listed above in a meaningful way, and without causing any spikes. Last week, there was a major ATM hack in the US , and that is sure to be overshadowed soon enough by some other security incident.  We hear about security failures all the time - Why not take a minute to recognize progress?    http://www.tufin.com/blog/rss/blog/posts/2013/may/network-abstraction-setting-the-stage-for-the-future-of-network-security-automation/ http://www.tufin.com/blog/rss/blog/posts/2013/may/network-abstraction-setting-the-stage-for-the-future-of-network-security-automation/ Mon, 13 May 2013 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2013/may/identifying-cisco-ios-type-4-passwords-with-securetrack/ Cisco recently cautioned about a security weaknesses on some versions of IOS and IOS XE-based routers, switches and appliances. The risk is related to a certain type of password (Type 4) that could allow an authenticated remote attacker to access sensitive information on a targeted device. Cisco recommends to check whether such passwords exist on your Cisco devices and to replace them with Type 5 passwords. While Cisco has provided a method to test devices for existence of these problematic passwords, you may still want a way to ensure that such passwords are not introduced anytime in the future. Here's a custom device configuration test that we developed to identify any Type 4 passwords across your router inventory and also to alert if such a password is mistakenly configured in the future. Assuming your routers are defined in SecureTrack, follow these instructions to test them: 1. Add the custom test by running this command on the SecureTrack server: curl -k -u <user>:<password> -X POST -d '<dcr_test_concrete><groupId>8</groupId><id/><name>Forbid Type 4 Passwords</name><isActive>true</isActive><isDefault>true</isDefault><risk>3</risk><severity>3</severity><testDef><description>Verify that Type 4 passwords are not configured.</description><expression>^(enable secret 4|username.*secret.4)[^\n]*</expression><id/><input>running_config</input><isCustom>true</isCustom><mustContain>false</mustContain><name>Forbid Type 4 Passwords</name><products><device>IOS</device><id>1</id><vendor>Cisco</vendor></products><remediation>Replace Type 4 passwords with Type 5 passwords.</remediation><testDefUid>CU001</testDefUid><type>line_match</type></testDef><testUid>CU001</testUid></dcr_test_concrete>' -H "Content-Type:application/xml"  "http://localhost:8080/securetrack/api/dcrTests/custom" 2. Create a new device configuration report under Reports 3. Enable the new custom test:    4. Save and run the report 5. A properly configured device should pass the test like this:       http://www.tufin.com/blog/rss/blog/posts/2013/may/identifying-cisco-ios-type-4-passwords-with-securetrack/ http://www.tufin.com/blog/rss/blog/posts/2013/may/identifying-cisco-ios-type-4-passwords-with-securetrack/ Thu, 02 May 2013 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2013/april/how-to-improve-dba-and-security-team-relations/ Dark Reading published a story today on How To Improve DBA And Security Team Relations .  It's s topic that is near and dear to our hearts here at Tufin, because it is reflects a convergence within IT Operations that profoundly impacts our customers. Unfortunately, opening up those communications channels has been much more difficult than anyone could have anticipated.  Differences in context, lingo, and overall objectives (availability/access as opposed to security) have had a polarizing effect. 70% of respondents reporting application service disruptions up to 20 times per year due to configuration changes, the financial and operational consequences are severe (the full report can be found here ). This conundrum played a major part in our decision to develop SecureApp.    SecureApp creates a common interface and shared context for network security teams to collaborate with their new partners - application managers - in a much more efficient and productive way.  We knew we were onto something when we began developing SecureApp a couple years ago.   Seeing stories like this validates that our roadmap and vision is aligned with what is happening in the industry…. Have you been experiencing this?  If so, we would love to hear you experience!      http://www.tufin.com/blog/rss/blog/posts/2013/april/how-to-improve-dba-and-security-team-relations/ http://www.tufin.com/blog/rss/blog/posts/2013/april/how-to-improve-dba-and-security-team-relations/ Mon, 22 April 2013 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2013/march/real-time-deutsche-telekom-cyber-attacks-map-highlights-the-fact-that-growing-numbers-of-firewalls-are-not-working-properly/ Deutsche Telekom's new and interactive real-time map of global cyber attacks is significant because the bulk of attacks (27.3m last month) identified by the Sicherheitstacho service were against the Server Message Block (SMB) - aka the Common Internet File System (CIFS). This attack vector operates across an application-layer network protocol that is mainly used for providing shared access to files, printers, serial ports, and miscellaneous communications between nodes on a network. With over 226 million SMB attacks tracked last month - compared to 800,000-plus against the NetBIOS services, 680,000-plus on port 33434 and 600,000-plus against SSH - this highlights the fact that businesses - and high-end consumers - are losing control over their network resources - including their firewalls. The results of this real-time and rolling analysis from Deutsche Telekom - which takes in data from almost 100 honeypot-style sensors around the world - confirms the findings of our annual Firewall Management Survey , details of which were released late last month, and which found that half of businesses audit their firewalls just once a year and, and 15% never audit their firewalls at all.  The problem with controlling the firewall in many organizations - and why SMB/CIFS attacks make it through - is that modern firewalls need to be regularly updated to cope with configuration changes, with 70% of the 200 respondents to Tufin's annual survey reporting application service disruptions up to 20 times a year due to configuration changes. We found that 93.6% of all firewall change requests are application-related, this confirms our observation that the function of firewalls has evolved to include secure application connectivity - in addition to their traditional role of perimeter security. The problem highlighted by Deutsche Telekom's new cyber attack service - is that cybercriminals are clearly exploiting the loopholes that arise as a result of these changes. You can see Deutsche Telecom's interactive map here Read the Annual Firewall Management Survey http://www.tufin.com/blog/rss/blog/posts/2013/march/real-time-deutsche-telekom-cyber-attacks-map-highlights-the-fact-that-growing-numbers-of-firewalls-are-not-working-properly/ http://www.tufin.com/blog/rss/blog/posts/2013/march/real-time-deutsche-telekom-cyber-attacks-map-highlights-the-fact-that-growing-numbers-of-firewalls-are-not-working-properly/ Wed, 20 March 2013 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2013/march/firewall-application-nightmares/ Enterprise security presents its own special headaches for most developers and application owners. It's not that every enterprise eco-system needs to be so complex that application deployment is impossible - they just seem to be managed that way.   I recently wrote a piece published on Computer Weekly which discusses the headaches associated with deploying apps for developers and application owners and how it can be so easy to overcome them. Have a read of the article here to find out more: http://bit.ly/XbhchW. If you'd like to discuss how we can ease your network security management headaches with a  groundbreaking approach,  please  let us know .  You can also read the new  Annual Firewall Survey Report  which has some interesting statistics thay may surprise you!   http://www.tufin.com/blog/rss/blog/posts/2013/march/firewall-application-nightmares/ http://www.tufin.com/blog/rss/blog/posts/2013/march/firewall-application-nightmares/ Wed, 13 March 2013 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2013/march/what-is-the-‘connection’-between-application-enablement-and-security-management/ By all accounts, the RSA Conference last week in San Francisco was a resounding success. If the interest and excitement at the Tufin booth was any indication I'm confident that 2013 will prove to be a year where Business and IT work more closely than ever out of sheer necessity if nothing else. Over the course of 4 days I had the opportunity to speak to over 100 customers, vendors and system integrators of all shapes and sizes who shared several similar challenges: Additional Compliance Requirements (Internal and / or Regulatory) Application Availability and Business Continuity Increase in Complexity Constant  Change Communication Gaps (between respective IT Organizations as well as Business Units) IT Staff at all levels are burdened with an ever increasing number of requests for user access, new applications, updates to current applications, adds moves and changes, the list goes on…  And when the evolving threat landscape is taken into consideration it becomes abundantly clear that simply accommodating these requests by creating a new security rule is far from best practice. Without a clear understanding of newly required, and existing, rules and policy you are putting business continuity and the security posture of an organization at severe risk. With that said why do we still see challenges, specifically in the areas of communication, between IT Security and Application Teams? Well, based on my conversations it seems operating in siloes has been acceptable if not functional. Until now that is… Consider the problems that hinder application enablement by asking yourself: How many security changes are required to enable your application demands? What percentage of my Firewall Rule Change requests are application related? Can your teams provision and/or decommission applications without having to sort through numerous security rules? Is the process automated? How often do applications get provisioned correctly the first time? Do decommissioned applications ever get completely removed from your environment? If not, can you identify who has unneeded access? Can you ensure continuous compliance? These are some of the issues covered in Tufin's new Annual Firewall Survey report - have a look at the results - you may be surprised to learn you're not alone. Someone smart once told me that "The Application IS the Business." Well if that's true to any extent, and I believe it is, than these questions need to be addressed. If you paid us a visit last week while at RSA, then you have some of the answers.  If not, set up a meeting and learn how we can help you to solve these challenges.     http://www.tufin.com/blog/rss/blog/posts/2013/march/what-is-the-‘connection’-between-application-enablement-and-security-management/ http://www.tufin.com/blog/rss/blog/posts/2013/march/what-is-the-‘connection’-between-application-enablement-and-security-management/ Thu, 07 March 2013 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2013/february/don’t-forget-network-operations-and-security/ I just returned from 3 very busy days at Cisco Live 2013 in London. We met people from companies around Europe, Middle East and Russia and had over 80 meetings with folks who have very specific challenges which need attention. Almost without exception, everyone we spoke to is experiencing the same issues: Their growing firewall rule set The ever-increasing  ACL in their Cisco routers and switches Pressure from their organization to deliver flexible security, that meets compliance, regulations and internal policieswithoutcausing significant delay to daily business operations. This can seem like an almost impossible challenge. If you are trying to manage these challenges every day, you probably agree that working in a mixed firewall vendor environment, combined with large and complex ACL's maintained in CLI are tasks that give you very little time to reflect on the rules you create and have created. While some firewall vendors offer tools to ease the burden of administration, none of them deliver tools that can handle and work across multiple vendors.  The majority of the people we had meetings with at the show are responsible for a business network that combines both multiple firewalls and multiple network vendors. If you were at Cisco Live, you will know that it is a large event which covers a lot of technologies.  These days there is a lot of media coverage concerning Cloud Computing, SDN, video and data center virtualization. With all the focus on these areas, it seems that the people administrating the firewalls and the network are sometimes forgotten.   It may be that firewall, routing and switch administration does not have the same "buzz" as other areas in the IT industry, yet it is still a fact that a mishandled network device can cause down time, network breaches or even worse, loss of money and productivity. After Cisco Live, I was asked to provide some feedback and observations from the event. I will spare you from reading about the event itself and instead I'll share the challenges we heard and the solutions we can help with: How to document firewall rules in real time How to report, document and analyze mixed vendor firewall and network equipment How to compare and document firewall rule set against previous rule sets How to map firewall rules with applications, owners and ticket ID's. How to do configuration audits on Cisco IOS devices How to incorporate company IT polices into Change Automation How to automate risk analysis How to map the network How to document redundant and unused firewall policies and objects How to minimize the gap between the application owners and network operations How to minimize time of delivery in firewall change requests How to automate and implement change requests into firewalls How to handle PCI-DSS and other regulatory challenges How to proactively handle audits So if you are reading this and facing some of the above challenges, contact me for a chat to see how we can ease your burden, without compromising your security. Reach out to me on Twitter and LinkedIn http://www.tufin.com/blog/rss/blog/posts/2013/february/don’t-forget-network-operations-and-security/ http://www.tufin.com/blog/rss/blog/posts/2013/february/don’t-forget-network-operations-and-security/ Wed, 06 February 2013 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2013/january/making-sense-of-firewall-rule-documentation/ Firewall rules must be documented but it's rarely done correctly. For a busy security administrator, the effort it takes to find the business justification for hundreds of rules and access lists that were entered by admins long-gone is an insurmountable task. And there are additional challenges - most enterprise firewalls just don't have the features required to complete a thorough documentation project. A single 'Comments' field with a length limit cannot contain the required critical information for proper documentation, and reporting capabilities are usually non-existent. Assuming you've somehow managed to document your rules, how do you maintain them? Each and every policy change must be supplemented by the relevant documentation, but will admins really remember to document during an urgent change request? If this sounds all too familiar, don't panic, you're in good company. Most enterprises including some of the largest organizations and service providers in the world, have similar challenges. Realizing the importance of firewall rule documentation, we have provided a solution within our firewall policy management suite. Although it's been there for quite a while, we've recently added some important capabilities. You can now maintain centralized rule documentation across major enterprise firewalls with 5 fields per rule or ACL: -   Technical owner -   Ticket ID -   Business owner -   Expiration date -   Description Rule metadata can now be edited manually or injected automatically via SecureChange access requests. Advanced filtering enables you to identify rules across firewalls that match certain criteria. These may include rules owned by a certain person, rules that are about to expire or even rules that are not associated with a ticket and are therefore not justified by business. This is particularly important because they present a real challenge for PCI DSS compliance. You can generate reports and you can also trigger alerts for rules that are about to expire to kickoff the recertification process. What about home grown documentation systems? Our professional services team is readily available to migrate the data or even to integrate both systems. Rule documentation has never been a fun task, but now you can tackle it more easily and improve your security. http://www.tufin.com/blog/rss/blog/posts/2013/january/making-sense-of-firewall-rule-documentation/ http://www.tufin.com/blog/rss/blog/posts/2013/january/making-sense-of-firewall-rule-documentation/ Thu, 31 January 2013 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2013/january/tufin’s-sko-2013-welcome-to-the-hotel-tufinforniastar/ The Negev Desert, in Israel's Southern region, became the stage for the finale of Tufin's Global Sales Kick-off Week 2013. After three days of intensive and productive meetings in Tel Aviv, the Company employees boarded buses for the rugged, expansive terrain. The globally diverse team had the unique opportunity of coming together to participate in challenging activities in the great outdoors. Enduring the dangerous curves and bumps on a mountain bike trip, overcoming a strenuous climb in a canyon, and surviving a 40 minute camel ride (truly a one-time experience, and no more)… each and every one came out a true trouper. The evening led to loud laughs, authentic food and good spirits. Talents shone brightly during a company "talent show", dancing prowess was demonstrated on the dance floor, and sleeping in a Bedouin tent 'en masse' further corroborated our survival skills (personally, despite the sound effects, I slept like a baby!... must have been that desert air). Being new to the company, I recognized that I had become a part of something bigger, something great. In this day and age, it is rare to find a workplace which possesses an inherent company culture where people are not only professional and dedicated, but also talented and inspired in other aspects, bringing a unique diversity and creating an atmosphere of creativity and vision for the future. As 2013 begins and promises to be an exciting year for Tufin, if I find myself on a dark, desert highway… or more likely, elsewhere, I might just pause and smile, and hum to myself… "Welcome to the Hotel Tufinfornia… Such a lovely place."    Mountain bike trip in the Negev desert   One time experience riding a Camel The SEagles singing their version of "Hotel Tufinfornia" Ole!   * Hotel Tufinfornia is a spoof song performed at the sales kickoff by the SEagles Band, from Tufin's US sales team. http://www.tufin.com/blog/rss/blog/posts/2013/january/tufin’s-sko-2013-welcome-to-the-hotel-tufinforniastar/ http://www.tufin.com/blog/rss/blog/posts/2013/january/tufin’s-sko-2013-welcome-to-the-hotel-tufinforniastar/ Wed, 23 January 2013 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2013/january/nather’s-law-of-policy-management/ A few months ago I read an article by Wendy Nather in Dark Reading about policy exceptions that really resonated with me.  According to 'Nather's Law,' "For every configuration there is an equal and opposite exception." Her point was that because exceptions are a) prevalent and b) directly correlated to risk; understanding how they impact your policy matters - a lot. She is so right.  Firewall and router policies are critical controls that require ongoing management. While there are, of course, valid reasons to create exceptions, they are a part of - and not abstracted from - the overall policy. Lately I've been noticing more and more requests for exceptions in our products for various audits and tests we perform. Many of them sound legitimate and make perfect sense at first approach. But if you have too many exceptions your policy becomes worthless. Here is the dilemma: As soon as an exception is flagged, when asked how long the exception should remain in place the answer is often "forever".   "Then why have the policy in the first place?"I think to myself as I politely grin and nod my head. From what I have observed, policy exceptions tend to occur because: An organization creates a policy that, in theory, makes total sense (or is required), but in reality is not practical. Regardless, it stays in effect. A well thought out policy cannot be cleanly translated into firewall rules, resulting in the need for constant workarounds (aka exceptions). The policy was based on a requirement that is either no longer current or necessary, but the change in necessity was never conveyed to the firewall team. If our compliance/operations/security efforts are changing at a rate that our typical firewall engineer, or our business itself, cannot keep up with, then…what have we developed? A mess, that's what. So how about we start thinking about some reasonable measurements and tracking our exceptions? If a compliance policy, or control policy, has more than x exceptions it should be flagged. If an exception has been in place for more than x months it should be flagged. If a given firewall rule violates more than x policies it should be flagged. If more than X% of a firewall rule base are exceptions it should be flagged. That last one is of particular interest to me today, as I saw a client recently with a rule base for his firewall that was around 1000 rules long. When looking at his compliance results for policy and risk he was showing me hundreds of rules he wanted to mark as exceptions. I was puzzled  - almost two thirds of his rule base consisted of exceptions to the compliance policies they were trying to enforce.   WHAT???  Two thirds of the whole policy?   Yep…I almost had to walk outside and have cigarette - and I don't smoke! Bottom line: if your exceptions are out of hand, it's time to rethink your compliance plans or realign operations with compliance.  It is one thing to lose track of how policy aligns with reality, another to not do anything about it. http://www.tufin.com/blog/rss/blog/posts/2013/january/nather’s-law-of-policy-management/ http://www.tufin.com/blog/rss/blog/posts/2013/january/nather’s-law-of-policy-management/ Thu, 10 January 2013 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2012/december/it’s-here-again!/ It's here again and I love it! No, not Santa and not mistletoe, but The End of The Year. It's the time when The Internet is filled with fantastic images to remind us what happened in 2012, lest we forget. I love the photos and can spend hours clicking through the online memories of the year (almost) gone by. This is one of my personal favorites . The End of The Year is also a time for summaries, market trends and predictions for the coming year - no matter what business you're in. Reuven Harrison, Tufin's co-founder and CTO summed up the year and talks about the top trends security administrators dealt with this year, and what to expect in 2013 .  Join the conversation @tufintech and tell us how you'd sum up the year and what your predications are. http://www.tufin.com/blog/rss/blog/posts/2012/december/it’s-here-again!/ http://www.tufin.com/blog/rss/blog/posts/2012/december/it’s-here-again!/ Mon, 17 December 2012 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2012/december/pci-security-standards-council-recommends-continuous-compliance/ Recently the PCI Security Standards Council (PCI SSC) released the Payment Card Industry Data Security Standard (PCI DSS) Risk Assessment Guidelines Information Supplement . One of the PCI SSC's key recommendations isContinuous Compliance. It states "A continuous risk assessment process enables ongoing discovery of emerging threats and vulnerabilities, allowing an organization to mitigate such threats and vulnerabilities in a proactive and timely manner". Ongoing discovery of emerging threats and vulnerabilities for sections 1.1 and 1.2 (automated firewall operations) is made easy with Firewall Policy Management solutions that analyze policy changes in real-time. Rather than waiting for an audit to analyze and mitigate violations that accumulated over the audit period, identifying the violations as they happen enables resolving them instantly and maintaining compliance over time. If PCI compliance is maintained year round, then an audit no longer requires the time and efforts that usually go into the periodic preparation of supporting documentation. Additionally, organizations can prove a high security standard to their customers and control firewall-related threats and vulnerabilities in a proactive and timely manner. Download the full list of PCI-SSC guidelines   Learn more about PCI-DSS Read more on Tufin's supporting compliance with SecureTrack . Watch the video: Get ready for your PCI Audit in 10 minutes Watch Christopher Graham, UK Information Commissioner and  Michael Hamelin , Chief Security Architect, Tufin, discuss  the importance of continuous compliance . http://www.tufin.com/blog/rss/blog/posts/2012/december/pci-security-standards-council-recommends-continuous-compliance/ http://www.tufin.com/blog/rss/blog/posts/2012/december/pci-security-standards-council-recommends-continuous-compliance/ Mon, 10 December 2012 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2012/november/my-thank-yous-this-thanksgiving/ It's that time of year - the weather is getting colder, Thanksgiving is upon us, and you can almost feel the end of the year, right around the corner. In the spirit of Thanksgiving, I wanted to take a moment and reflect on three things that I am most grateful about (professionally) this year: 1. Our customers - there's nothing more satisfying than meeting customers that say: "I really love your product - I can't imagine what my work would be like without it". Many customers recommend Tufin to friends in the industry and become our champions - I'm very grateful that we have such a loyal group of customers.  2. Our employees - I love the energy and enthusiasm that our employees have, their compassion for each other in times of need, and their talents - it's a very smart group of people… I'm often amazed by what we've been built, and it's all based on the people that we have. In Tufin's "Guiding Principles" (our company philosophy and values), the first principle is "Focus on People", and it shows. 3. My Co-founder and business partner, Reuven - having a great partner means someone that you can truly count on, someone who shares the responsibility, someone that balances your thoughts and personality, someone that provides a unique and fresh perspective on things. I could not have done this without Reuven, and I'm honored to have him as my partner, and my friend.  Happy Thanksgiving everyone! http://www.tufin.com/blog/rss/blog/posts/2012/november/my-thank-yous-this-thanksgiving/ http://www.tufin.com/blog/rss/blog/posts/2012/november/my-thank-yous-this-thanksgiving/ Thu, 22 November 2012 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2012/november/why-you-should-automate-your-firewall-policy-before-the-holiday-season-starts/ In 2009 Tufin conducted a survey of about 100 hackers at Defcon .  About 81 percent said they were "far more active" during the winter holidays than during the summer. Fifty-six percent named Christmas as the best time to engage in corporate hacking, while 25 percent named New Year's Eve. Are you ready? Don't wait for a breach, a threat of a breach, a slew of bots hammering on your firewalls, a disgruntled employee, or an audit to be the catalyst for you to find out that your firewalls are not running optimally.  While firewall management often seems a daunting task, policy changes don't have to be painstaking, labor-intensive chores that must be performed by an expert. Automated solutions that effectively take over routine, manual work and free up experts for strategic tasks, save organizations valuable time and ensure they are both compliant and secure. Automating your firewall policy management means that you will be ready for whomever comes a-hacking at your firewall door, regardless of when your audit is due. Watch Christopher Graham, UK Information Commissioner and Michael Hamelin , Chief Security Architect, Tufin discuss the importance of continuous compliance . Automating firewall management solutions will catch things that are virtually impossible to flag manually - for instance, that rule 71 is partially shadowed by rule 273, which in turn results in a certain group of database admins having overly permissive access. That is all a hacker needs to know to get inside without even having to hammer through the firewall.  But by learning how to optimize an overly permissive security policy , or how to create a new policy for an unprotected network segment , Mr. Hacker won't be having such a Merry Christmas. While you can't stop the bad boys and their toys, you don't have to unblock and clean out the chimney for them to climb down either.  Making sure there are no gaps or exposures caused by the very systems you bought to protect yourself is a good place to start protecting yourself.   So go on, give yourself the gift of automation this holiday season before it's too late and you have to make it next year's New Year Resolution. http://www.tufin.com/blog/rss/blog/posts/2012/november/why-you-should-automate-your-firewall-policy-before-the-holiday-season-starts/ http://www.tufin.com/blog/rss/blog/posts/2012/november/why-you-should-automate-your-firewall-policy-before-the-holiday-season-starts/ Mon, 19 November 2012 00:00:00 Kate Shopper http://www.tufin.com/blog/rss/blog/posts/2012/october/results-of-tufin’s-application-connectivity-management-survey-released/ The results of a  Tufin's survey  of 140 network security professionals reinforce the fact that enterprise application connectivity-related issues are now driving the vast majority of firewall changes. However, few of them have effective processes in place to account for this shift, and almost one fifth said they don't have any processes in place for managing enterprise application connectivity-related firewall data at all. Read the report.   31% say their organization may have had a security breach due to an application-related rule change, and 64% experienced application service disruptions (due to network configuration changes) up to 10 times per year. These findings and others like it highlight the business case for  SecureApp  and reinforce the case that Application Connectivity Management is no longer a 'nice to have', but a 'must have'. For more information: Download the full report Read the EMA analyst report Read our white paper Read the press release http://www.tufin.com/blog/rss/blog/posts/2012/october/results-of-tufin’s-application-connectivity-management-survey-released/ http://www.tufin.com/blog/rss/blog/posts/2012/october/results-of-tufin’s-application-connectivity-management-survey-released/ Mon, 05 November 2012 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2012/october/secureapp-–-the-next-step-in-tufin’s-evolution/ In September we announced the third component of the Tufin Security Suite solution, SecureApp . This marks an important milestone in Tufin's evolution which I would like to share with you. Ruvi and I started Tufin almost nine years ago and we released the first version of SecureTrack about a year later. SecureTrack had great appeal to firewall administrators whose main challenge was to manage large firewall policies on multiple firewalls. We named the market "Firewall Operations Management". We expanded SecureTrack to support multiple flavors of enterprise firewalls and additional capabilities such as audit, compliance and policy analysis and our company grew at a fast pace .                                                                                     In 2008 we welcomed SecureChange to our family. It was a natural step as we discovered that firewall policies are not only very complex but also very dynamic. Now, in addition to monitoring changes and optimizing their security policies, our customers could engage in the change process at an earlier phase and be more proactive about it. Gartner referred to this extended market as "Firewall Policy Management". In 2009 we invented the Automatic Policy Generator (APG) which was an instant hit. It answered a need that many of our customers had: "How do I get rid of the overly permissive rules?" but the requirement hid an implicit necessity: "Without disrupting business!" Continuing our tradition of innovation we recently announced SecureApp . This is the next phase in the evolution of Tufin's Security Suite (TSS) of products and it represents a revolution in the industry. This new concept aims to bridge a critical gap between application teams and IT operations. As usual, Tufin is creating a new class, not just a product. Enterprise applications are a vital aspect of business and for many large organizations they ARE the business. The majority of our enterprise customers have hundreds, if not thousands of them but they are finding that IT operations and network security processes are holding back timely delivery of these crucial services. SecureApp accelerates service delivers by streamlining the network and security change process. Prior to the launch we conducted a survey among our largest customers. It showed that their requirements have changed and that firewall policies can no longer cope with what is expected of them. While firewalls were initially designed as a perimeter gateway, enterprise application connectivity-related issues now drive the vast majority of firewall changes. However, few have effective processes in place to account for this shift. The interest in SecureApp has been wide-spread and multi-channel. It has included coverage in some of the most influential publications in the industry and papers from industry analysts . http://www.tufin.com/blog/rss/blog/posts/2012/october/secureapp-–-the-next-step-in-tufin’s-evolution/ http://www.tufin.com/blog/rss/blog/posts/2012/october/secureapp-–-the-next-step-in-tufin’s-evolution/ Wed, 31 October 2012 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2012/october/why-secureapp-is-so-much-more-than-a-product-release/ For those who know me , you'll be aware that I don't have time to blog as often as I'd like. However, the launch of SecureApp last month represents much more than a product launch for me and I'd like to share the experience. The move towards application connectivity management demanded that I - together with my partner Reuven Harrison - had to be 100% sure that we were developing the right solution for the market. We knew this decision would affect not only the company, but our customers and channel partners as well. Below is the story about how we brought SecureApp to market.   This is part of a series of posts from Tufin who will share their SecureApp stories and experiences.  The Tufin team, our customers and partners are very important to us and we knew that the addition of SecureApp to our TSS ( Tufin Security Suite ) was going to be a major milestone for the company and effectively present the market with a completely new paradigm shift in security policy management. We would be able to offer a full, end-to-end suite for the first time in our history, which was, by definition, stepping into the realm of the unknown. So how could we be completely sure we were bringing the right solution to the market? In short, we asked the market. Over a year ago we approached 20 of our largest customers who had communicated the need for a completely new way of managing their security policies.  We shared our vision for SecureApp and Tufin's Security Suite and described how we saw the market evolving. The reaction was overwhelmingly positive. We had long, intense meetings with our design partners and were transparent about what we were doing and why. They offered us feedback and we changed requirements, functionality and priorities accordingly. And now, one month after our 'product launch', I look back and acknowledge that the journey was essential. I am very glad that we identified an important, yet unmet market need and developed an innovative solution for it.  To date, the response has been very encouraging, with customers , analysts and the media alike reinforcing our belief that Application Connectivity Management is the next frontier in firewall management. So, whether you have traditional firewalls or next-generation firewalls, you still need a solution to manage application connectivity top-down. In a word:SecureApp. Watch the video to learn more about how SecureApp can make a difference to your business. http://www.tufin.com/blog/rss/blog/posts/2012/october/why-secureapp-is-so-much-more-than-a-product-release/ http://www.tufin.com/blog/rss/blog/posts/2012/october/why-secureapp-is-so-much-more-than-a-product-release/ Sun, 28 October 2012 00:00:00 Michael Hamelin http://www.tufin.com/blog/rss/blog/posts/2012/october/application-connectivity-aware-firewall-management-–-part-2/ In my previous post , I shared some of my experiences from the SecureApp launch which encompassed 12 presentations in 12 different cities across two continents. One of my biggest take-aways was that network security teams have had a wide set of pains behind a wide set of application management issues for quite some time, many of which were impacting firewall teams that network security teams have had a wide set of pains behind a wide set of application management issues for quite some time, many of which were impacting firewall teams. That's how we came up with the concept for SecureApp .  SecureApp is a management console that sits above the firewall layer - above the network stack entirely - to separate application requirements from the hundreds of rules dispersed across multiple firewalls on the network. SecureApp enables network managers and application owners to work together to define, manage and update application connectivity requirements. It also provides a dedicated database for application connectivity data, meaning that data will finally be stored in a central repository instead of Excel spreadsheets, Word docs or firewall rule comments fields.  SecureChange acts as both the underlying engine and the means through which that abstracted data connects back to the network. Firewall management cannot be completely automated without SecureApp.  Not only does it reduce the number of changes that need to be redone, but the time (and associated cost) saved by not having to chase down data sitting in disparate devices is significant. We are confident that SecureApp will provide significant ROI, in addition to what can be achieved with SecureTrack and SecureChange . So far, the response to SecureApp has been great.  The question we get is not "how is this different than a Next Generation Firewall," but "how much will it cost us?"  My answer is usually "how much is it costing you NOT to have something like SecureApp?" http://www.tufin.com/blog/rss/blog/posts/2012/october/application-connectivity-aware-firewall-management-–-part-2/ http://www.tufin.com/blog/rss/blog/posts/2012/october/application-connectivity-aware-firewall-management-–-part-2/ Tue, 23 October 2012 00:00:00 Michael Hamelin http://www.tufin.com/blog/rss/blog/posts/2012/october/application-connectivity-aware-firewall-management-–-part-1/ This is the first in a series of posts from the Tufin team about how we brought SecureApp to market. Below is my story. Experts from multiple disciplines agree that analogies play a significant role in cognition, influencing explanation and communication. That is why college entrance exams in the U.S. test for the ability to correctly interpret analogies, and why I use them so often in my role as Tufin's Chief Security Architect.  Nothing helps to cut to the chase quicker than good analogy.  In fact, I was hoping the title could speak for itself, but in case it doesn't, here's the story behind it… In support of the launch of our newest firewall management product, SecureApp , I went on the road to present at a series of dinner events.  My role was to educate our customers and partners on what SecureApp is, how it fits into our existing product suite, and why we are confident that it will be the firewall management game changer we believe it to be.  Over the course of four weeks, I did 12 presentations in 12 different cities across two continents, one of my biggest take-aways from these dinners, was that network security teams have had a wide set of pains behind a wide set of application management issues for quite some time, many of which were impacting firewall teams.   It is only because the firewall management market has matured to its current state that they were even in a position to address them, and that we were in a position to really help. Seven years ago, our customers' biggest pain was devicecomplexity (e.g. - bloated rule bases).   SecureTrack was the answer to that problem.   Once they got a handle on managing their devices, processcomplexity (e.g. - security change automation ) took center stage, which resulted in our bringing SecureChange to market.  But as good as SecureChange is, automating change management processes doesn't eliminate the fact that  firewalls were not designed with application connectivity in mind, and as we all know, these days corporate IT is all about applications An organization with complex enterprise applications performs anywhere from 30-100 firewall changes per week. In other words, Application Connectivity - managing how to bolt business critical applications onto the network in a secure and compliant way - drives the majority of firewall change requests.   However, in a recent Tufin survey we found that roughly half of all firewall changes need to be re-done.  When we dug into the survey data, we learned that the vast majority of the time, firewall changes are re-done because of missing, inaccurate or mis-communicated application connectivity requests. Part 2 of this post will look at how SecureApp   - our new application connectivity management platform - marks the beginning of a paradigm shift in the security policy management market by delivering a top-down approach based on business requirements, instead of a bottom-up approach based on configurations. I'm sure there's an analogy in there somewhere… http://www.tufin.com/blog/rss/blog/posts/2012/october/application-connectivity-aware-firewall-management-–-part-1/ http://www.tufin.com/blog/rss/blog/posts/2012/october/application-connectivity-aware-firewall-management-–-part-1/ Mon, 22 October 2012 00:00:00 Ruvi Kitov http://www.tufin.com/blog/rss/blog/posts/2012/september/today-is-the-day/ Today is the day. Today is an important milestone in Tufin's history. Today, we are announcing what we believe to be the biggest paradigm shift that firewall management has experienced in the last 20 years. And even though…. IT teams are now managing hundreds of firewall rules across multiple servers Over 90% of IT security teams say that they now spend more than half their time on application management Request the survey 1 in 3 say specialists report security breaches as a result of application-related rule changes  …. There have been no major advances in firewall management. Until today.   That's why we at Tufin see today as the end of the Firewall Policy Management evolution and the start of the Firewall Policy Management Revolution. It's called Application Connectivity Management. Application Connectivity Management means that you can now manage your network top-down: starting with the application and moving onto network security. Application Connectivity Management means that your application deployment time is quicker and you have visibility and control over your applications from the network connectivity perspective. Application Connectivity Management means Tufin's SecureApp. Read all about it (link to SA web page) and tell us what you think at #TheFirewallRevolution add new LinkedIn group here I'd like to thank the entire Tufin team for making this happen: everyone who participated in the design, development, QA and customer interaction - it was truly a team effort, and it shows. I'm proud to be in the company of such a talented group of people! Most importantly - I'd like to thank the customers who helped us refine the ideas for SecureApp, and especially SIX Group in Switzerland (the Swiss stock exchange), who is the first customer to purchase SecureApp - we really appreciate all of your help, feedback and support! Ruvi More information: Watch the Movie Read the whitepaper Read More http://www.tufin.com/blog/rss/blog/posts/2012/september/today-is-the-day/ http://www.tufin.com/blog/rss/blog/posts/2012/september/today-is-the-day/ Wed, 19 September 2012 00:00:00 Shaul Efraim http://www.tufin.com/blog/rss/blog/posts/2012/july/so-many-consoles,-so-little-time/ Earlier this week we announced the findings from a survey we conducted this past April at InfoSecurity Europe.  Each year we ask how many separate network security consoles participants manage, and for the past two years the answers have been almost identical: 44% of respondents manage 6 or more consoles - with 32% of that 44% managing 10 or more. Since everyone that participated in the survey was directly involved with firewall operations, and most work for mid-to-large sized organizations, it is highly likely that several of these consoles are firewall consoles. The majority of our customers manage firewalls from multiple vendors.   Managing rule bases for multiple firewalls is complicated enough, especially when the average firewall rule base consists of hundreds and sometimes thousands of rules.  Managing rules for tens to hundreds of firewalls from multiple vendors adds additional complexity and room for error when done manually.  For organizations that fit that profile, the ROI for a firewall operations and compliance solution can be dramatic. Think about it:  let's say you are for the most part a Check Point shop but you inherited some Juniper Networks and Fortinet firewalls via acquisition or technology transition. Your company is subject to PCI DSS, which means you are required to do periodical firewall audits. Preparing for those audits can be a daunting task in itself - and that doesn't take into consideration the operations piece:     How can you manage firewall risk within each firewall and across the entire, multi-vendor estate?     How can you manage rule changes?     How can you make sure that policies are normalized and optimized so that you are not taxing the firewall unnecessarily or implementing inefficient changes?     How can you ensure that a change won't introduce a security breach or compliance violation?     How can you normalize the performance of several firewall admins each with different knowledge and experience levels?     How can you automate compliance checks for regulatory compliance standards or internal policies? Implementing a firewall operations solution will dramatically ease the pain of managing multiple firewalls- instead, you can centralize firewall management so that you have a single, a top down view into the security and compliance posture of your entire firewall estate. Once you have that in place you can start applying some of the benefits of automation  - especially when it comes to daily operations - plotting changes and checking those changes proactively against security and compliance requirements; normalizing policies across the entire organization making sure all changes are properly documented, and there is a complete audit trail for each change. How do you think this would benefit your organization? For more on how firewall management can benefit your organization, check out our resources page for a wide variety of customer success stories, white papers, videos, webinars and more. Best, Shaul   http://www.tufin.com/blog/rss/blog/posts/2012/july/so-many-consoles,-so-little-time/ http://www.tufin.com/blog/rss/blog/posts/2012/july/so-many-consoles,-so-little-time/ Thu, 12 July 2012 00:00:00 Michael Hamelin http://www.tufin.com/blog/rss/blog/posts/2012/june/continuous-compliance-–-it’s-all-about-respecting-your-customers/ While at InfoSecurity Europe last month, I had the pleasure of interviewing Christopher Graham, the  ICO  UK Information Commissioner. I was giving a talk on the concept of  Continuous Compliance  and what that means from a firewall/network security perspective at the show. As the ICO is a UK regulatory body, I thought it made sense to sit down with Christopher to discuss why companies should focus on compliance, and I'm glad I did. While many would agree that a proper compliance program is critical to protecting an organization's brand, Christopher framed it in a way that really resonated with me. Many UK driven compliance initiatives have to do with privacy. The way Christopher sees it (and I agree with him 100%), maintaining customer privacy is all about respecting your customers. Companies are in business because our customers trust us, and if they don't trust us then why should they do business with us? As ICO's Information Commissioner, Christopher can levy fines up to 500,000 British Pounds to companies that, in his words, "get things spectacularly wrong." However, there is a wide spectrum as to why a company might get fined. There is a big difference between malicious intent - a company with no respect for their customers who engages in unethical business practices versus a company that was trying to do the right thing but was still compromised. In the second example, things "go wrong" because maintaining compliance is a daily task prone to human error. To make things "go right", constant vigilance is required - in other words, ensuring sufficient measures are in place to adequately protect customer data in the first place. And that's where Continuous Compliance is key. Continuous Compliance is not about checking a box - it is about respecting your customers' privacy, and making sure the proper technology controls are in place to accomplish that. I encourage you to  check out my video interview with Christopher , as we can all benefit from heeding his advice not to "play fast and loose with customer data". Best, Michael Hamelin Chief Security Architect http://www.tufin.com/blog/rss/blog/posts/2012/june/continuous-compliance-–-it’s-all-about-respecting-your-customers/ http://www.tufin.com/blog/rss/blog/posts/2012/june/continuous-compliance-–-it’s-all-about-respecting-your-customers/ Tue, 12 June 2012 00:00:00 Eric Ogren http://www.tufin.com/blog/rss/blog/posts/2012/june/guest-post-by-eric-ogren/ Are you ready for this? It is just not becoming more commonly seen even though it has been around since 1999. That is what an IPv6 address looks like and you are in good company if you believe the new IP address format will break custom scripts, firewall management spreadsheets, and cause integration headaches as you evolve to the new world of IPv6. June 6 th  marks World IPv6 Launch day ( http://www.worldipv6launch.org/  and  http://www.ipv6actnow.org/ ) which will showcase major service providers demonstrating IPv6 connectivity between thousands of network devices. While there are definite functionality benefits of IPv6 networking, the main reason for its existence is the need for more IP addresses than can be supported under IPv4. In fact, it is the need to express 340,282,366,920,938,463,463,374,607,431,768,211,456 unique addresses that results in a longer hex address syntax that will cause the most compatibility troubles for your existing IPv4-based network and security management tools. For all of you, the transition to IPv6 is a process that is going to take years. You simply have too many network devices and servers running the business for any kind of rapid switch-over to be pragmatic. That means you will be dual stacking IPv4 and IPv6 in your environment, with address schemes that are not directly compatible. Attention to detail in network and security management tools will save you significant pain later. Imagine those first calls to the IT service desk with errors induced by long IPv6 addresses that are too long to accurately read over the phone and compounded by tools that do not easily accommodate IPv4 and IPv6 requirements! You can avoid those invigorating moments of pandemonium by ensuring that your firewall and network management tools properly handle IPv6: Require all new devices to support IPv6.  Clearly specify IPv6 support in RFPs and include dual stacking requirements in all proof of concept projects.  You cannot afford to have software, servers, or communications equipment in your network that cannot participate when the business mobilizes towards IPv6. Switch to automated management tools.  Many of you still maintain relationships between IPv4 addresses in spreadsheets and use custom scripts to help perform administrative activities. You can certainly invest in upgrading your home-grown capabilities, but now is a good time to investigate alternatives. Debugging spreadsheets of IPv6 and IPv4 addresses, along with dynamic access rules and relationships, is notoriously difficult and complex. There are tools such as that shown by Tufin that can help you evolve smoothly to IPv6. Detect IPv6 servers and objects as they come online.  This is actually a tool requirement that is important enough to call out separately. You will need to be able to automatically detect and locate IPv6 elements as they come online, and then check firewall rules and access control lists to ensure connectivity and adherence to security policy. You should be looking to automate detection and policy compliance checking to ensure seamless evolution of connectivity without opening the business to the risk of a disclosure incident. There can no longer be any question that IPv6 is coming. The original allocations of IPv4 addresses expired in February, 2011 and the present system of recycling used IP addresses cannot be sustained forever. Deriving and executing a strategy for the evolution to IPv6 is something that all organizations should be involved in. Instituting administrative processes with modern security and network management tools is a critical first step in ensuring a smooth transition for the business and compliance with network security policy in an IPv6 world. fdfe:dcba:9876:2:20e:cff:fee4:2ee6 is coming - get ready!   http://www.tufin.com/blog/rss/blog/posts/2012/june/guest-post-by-eric-ogren/ http://www.tufin.com/blog/rss/blog/posts/2012/june/guest-post-by-eric-ogren/ Wed, 06 June 2012 00:00:00 Michael Hamelin http://www.tufin.com/blog/rss/blog/posts/2012/may/the-more-things-change,-the-more-they-stay-the-same/ When Tufin Co-founders  Reuven Harrison  and  Ruvi Kitov  first developed  SecureTrack , the product was primarily focused on change tracking, in order to  provide  firewall administrators a way to gain visibility into their rule bases.  At that time (around 2004),  there were very few tools available to provide any sort of insight into a rule base beyond what you could see on a firewall management console, and they provided very basic configuration management. A lot has changed since then.  The market for firewall management solutions is mature - we have automated very  granular and sophisticated policy, risk, compliance and change management capabilities, and the road map is only getting longer.  However, despite all the cool and increasingly necessary additions, when it comes to firewall rules, administrators tend to make the same mistakes, and have the same challenges.  The main difference is that the environments they are making the mistakes in are much more complex.  As a result, the potential fallout from those mistakes may be more severe, and likely impossible to resolve without automation. I encourage you to take a look at my  recent article on firewall metrics .  I came up with these benchmarks based on my own experience as an administrator, and from extensive interaction with Tufin customers.  Did I get them right?  Did I leave something off that is essential to your organization?  If you are using Next Generation firewalls, have they changed what we should measure and why? We'd love to hear from you, so let us know! Best, Michael   http://www.tufin.com/blog/rss/blog/posts/2012/may/the-more-things-change,-the-more-they-stay-the-same/ http://www.tufin.com/blog/rss/blog/posts/2012/may/the-more-things-change,-the-more-they-stay-the-same/ Thu, 03 May 2012 00:00:00 Michael Hamelin http://www.tufin.com/blog/rss/blog/posts/2012/april/michael-hamelin-on-crafting-a-firewall-maturity-model/ Crafting a Firewall Management Maturity Model Over the years, many have proclaimed the death of the firewall, but it has yet to happen. In fact, with the advent of next-generation firewalls and the availability of mature solutions that automate firewall management, the firewall is undergoing something of a renaissance. If you have ever looked at a firewall rule and wondered how it got there, or have been afraid to delete or modify a firewall rule because you were concerned you might break something ,then you might want to think about elevating your organization's firewall management efforts to a higher level. Regardless of whether you have one or 100 firewalls, creating a repeatable, sustainable process for firewall management can bring immediate time and cost savings and improve an organization's ability to manage its network security risk and compliance posture. The maturity model below can help. The stages are based on evaluating how almost 1,000 companies have improved firewall management within their organizations - where they started, how they moved forward, and how they measured their own improvement. Because these stages should apply to any business of any size in any industry, there is no finite set of requirements to advance from one stage to the next. The idea is that you can use this model to help gauge where your organization sits on the firewall management maturity curve and how to move it along. Stage One: Immature At the lowest end of the scale are companies with no method to the madness. Changes are made as they come, and the process is mostly, if not completely, manual. For example, suppose a company pushes out seven new rules and changes to 30 objects within existing rules; mistakes could be not only explosive but also difficult and time consuming to correct. How do you know you're in this bucket? Well, if you answer "yes" to more than three of scenarios listed below, then chances are you're at level one and you can benefit  dramatically  from process improvements. You look up a change and have no idea why it was done or who did it. You look at a rule and wonder how it got there. Team members don't know why rules are on the firewall. Everyone is afraid to make a change to anything that exists. Every new rule is added to the top of your rule base. Firewalls are slow - rule bloat causes the device to take a long time to install a policy. You/your team spend a lot of time making sure changes work. A noticeable number of changes need to be redone. You are afraid to acknowledge what is not being done. Stage Two: Emerging: Emerging companies are those that are starting to put some structure and reporting around their firewall monitoring and change management efforts. Process automation is already underway and those involved are interested in making improvements. Instead of wondering why a change was made or what might happen if they delete or move a rule, firewall admins at emerging companies spend their time determining if a new access request should be met by changing an existing rule instead of crafting a new rule, or if changes can be grouped by service or destination. Emerging companies are likely to be using Excel and/or Word to manage changes. With some degree of audibility, they have visibility into metrics such as how many new rules, new objects, changed rules and modified objects occur during each change window. While they have much less security and compliance exposure than immature companies, they can still benefit from additional process automation. Here are some signs you are at this stage: Too much time is spent looking up data in spreadsheets. Documentation is messy and filled with errors. While there is more confidence around implementing changes, there are still concerns that deleting rules will break something. Optimization is welcomed - it's understood that rule bloat is simply the nature of having mature systems and it's a good thing to start streamlining them. Attention is given to change management processes - since ticketing systems don't account for the details for firewall changes, admins start to track them themselves. Stage Three: Mature: For the most part, mature companies have already implemented three things: 1)    An automatic system for monitoring configuration changes with accountability info.  Basic items such as who made each change on every firewall and when they made it are documented and auditable. Firewall rules can be automatically analyzed for risk and compliance, and the benefits of automation are quantifiable - at least anecdotally. 2)    An optimization strategy.  Teams are in maintenance mode, as opposed to undertaking a major initiative to clean out the rule bases, and have the people, process and technology resources needed to execute. 3)    Automated or semi-automated firewall change management processes . There are set change windows and an established (ideally automated) workflow process for change management that includes risk and compliance analysis for any given change request. Firewall administrators at mature companies have made significant strides on the operations side and are focused on fine-tuning  - especially when it comes to change management. However, despite process automation, they still lack business context. There is little or no communication with the business units, which is why change management is still difficult. Stage Four: Highly Mature: Highly Mature organizations have successfully implemented structure around their firewall operations and change management efforts. Instead of looking at the risk stemming from a single firewall, teams are assessing the risk posed by groups of firewalls, risk per zone, etc., and spending less time per change. All the details surrounding where to place a change in the rule base are automated and executed within established change windows, and changes on a firewall are automatically reconciled with ticketing systems. The time and motivation exists to assess change management processes for business risk.  Firewall administrators see themselves not just as engineers but also as contributors to the business. As a result, they are better equipped to respond to business changes via new compliance ands risk-related rules or processes. For example: A business decides it is going to start processing credit cards and the firewall team should be able to understand how that will impact them. Where do they need to store the Personally Identifiable Data (PII)? How will they protect it? When should they start with quarterly PCI audits? Other signs you have arrived at stage four: Firewall audits are fully automated, and no longer dreaded. You start hearing terms like "continuous compliance" used regularly. You can easily communicate about progress and improved integrity of systems. Because there has been positive feedback, teams are motivated to communicate improvements. Highly mature companies understand the impact IT can have on the business. Investments in IT Security, unlike most other areas of IT, are not intended to generate revenue and, as a result, in some organizations are perceived as a financial black hole. However, firewalls are core technology, and with the advent of next-generation firewalls are just as relevant now as they were 15 years ago, if not more so. Sometimes, good business simply involves applying common sense. In other words, why invest in a new set of less proven security technologies when you can dramatically improve the performance of and ROI on an existing investment? Investing in firewall management can deliver transformative results - especially if yours is a stage one organization - and can set the standard for how IT Security can and should function within a business context. So why wait? Michael Hamelin is the Chief Security Architect at Tufin Technologies (Burlington, MA). www.tufin.com   http://www.tufin.com/blog/rss/blog/posts/2012/april/michael-hamelin-on-crafting-a-firewall-maturity-model/ http://www.tufin.com/blog/rss/blog/posts/2012/april/michael-hamelin-on-crafting-a-firewall-maturity-model/ Mon, 02 April 2012 00:00:00 Reuven Harrison http://www.tufin.com/blog/rss/blog/posts/2012/february/tss-r12-1/ When we started Tufin there was little awareness as to the complexities of managing firewall policies. Most of the interest was around tracking firewall configuration changes and we only supported Check Point. This may seem trifling today, but our early adopters realized the business value of receiving a policy change report by email and they loved it. Seven years later we provide full support for the five leading enterprise firewalls, a graphical network topology model, a policy analysis module that simulates how packets are matched by rules, a security risk model, rule and object usage analysis, a firewall change request system and much more. Our 900 customers are using our solutions to streamline firewall operations, automate audits and manage the firewall change process. Our first version in 2012, R12-1, will be released in a few days and we've put some nifty features into it. First, there's  the new dashboard  that allows you to see a high-level overview of your risk posture as well as recent configuration changes across your infrastructure and the policy cleanup potential. Security officers can use the dashboard to monitor their security status and identify areas that require attention such as data centers, customers and specific firewalls. The firewall operations team can continue the drill-down using the risk and cleanup browsers and pinpoint the root causes such as risky rules or redundant rules. The dashboard conveys the real-time status of complex environments and allows effective navigation to analyze and remediate problems. The new policy analysis interface provides some functionality that many of you have been waiting for, like a fast and easy way to enter multiple IPs and Ports and to find rules that allow or block the access through one or more firewalls across the network, even with address translation (for Check Point in this release). The network topology map now allows you to insert router configs in order to improve path calculations. Juniper firewalls (ScreenOS and JUNOS SRX's) can now be monitored through NSM too, and Juniper SRX rule comments are now parsed to identify and report ticket IDs. Especially for you Jeremy   . One more interesting area of evolution in R12-1 is SecureChange - the access request has been enhanced to allow easier reading and editing.  The new Designer automatically recommends firewall rules that should be modified to cater for the access request and, once designed, the change can now be saved directly to a Check Point policy. Automatic provisioning also supports adding and removing members to network and service group. I wanted to take this opportunity to personally thank our customers and partners for working with us. Your partnership and trust is enabling us to provide better solutions and more value. Reuven http://www.tufin.com/blog/rss/blog/posts/2012/february/tss-r12-1/ http://www.tufin.com/blog/rss/blog/posts/2012/february/tss-r12-1/ Wed, 22 February 2012 00:00:00 Shaul Efraim http://www.tufin.com/blog/rss/blog/posts/2012/january/network-security-101-automating-for-continuous-compliance/ Managing access to confidential information and application resources via firewalls is the foundation of network security, and firewall audits are central to any mature network security process. However, relying on security and network experts to review rules across multiple firewall zones and different firewall products is proving to be costly and ineffective. Few will dispute that when it comes to network security, automating best practices to reduce operating costs, complexity, human error, and streamline processes is a good thing.   However, in what we call the age of Continuous Compliance - brought on by the reality that point-in-time audits done hastily to meet reporting deadlines rarely - if ever - deliver any security or compliance benefits once that point in time has passed, automation becomes more than just good.  It becomes essential. Case in point: a November 2011 survey from Tufin of 100 firewall managers revealed that only 1.3% of configuration changes that cause network downtime or pose a security breach are identified during the quarterly audit, yet almost a third of the respondents spent 3 to 7 days  per quarter  of valuable network security team time on firewall audits (Disclosure: I work for Tufin). Organizations receive precious few benefits for the level of resources spent on manual firewall audits. This  is proving to be an inefficient approach to maintaining a secure network and if you do the math, an extremely inefficient use of skilled security personnel. In general, best practices in security are mandated in standards such as the PCI DSS, DISA Information Assurance Support Environment, or healthcare's HIPAA.   Most if not all of these regulations - and many others, either specifically mandate or implicitly require firewall audits. The best practices of firewall audits are based on expert reviews of changes made by network and security administrators. In theory, errors are caught, corrections are made, and compliance is re-established as a result of the audit. In practice, errors are seldom caught and operational costs climb, in great part because audit teams discover security issues in firewall protection from manual audits at a very low rate. As the discipline of IT security continues to evolve, knowing where and when to automate can make or break a CISO's career - not to mention the morale and effectiveness of their compliance and IT operations teams. One of the important ways security teams gain efficiencies is to apply technology to evolve audit processes from disruptive quarterly or yearly events to daily standard operating procedures. The technology exists today to automatically verify compliance as firewall rules changes are implemented - ensuring continuous compliance with tight security and fewer calls to the security service desk. The complexities of modern networks are often simply too much for a human to decipher without assistance. Not only do the best security experts have to interpret rules languages across vendors such as Check Point, Cisco, and Juniper Networks, but they must also translate application-based rules from next generation firewalls (such as those from Palo Alto, Check Point,  SonicWALL, SourceFire) to ensure compliance with security policies across the organization. The concept of independent validation of firewall configurations is a good one - the best practice is now to have a security expert craft the new rules and then automate the impact on firewalls to ensure continuous compliance. Seeking continuous compliance via automation of firewall management has the additional benefit of preserving the valuable time of security experts. Instead of expending critical resources conducting manual reviews of firewall rules that are unlikely to result in improved security or enhancements to compliance, security teams are able to contribute to the business in more productive activities. Too much time - the 3 to 7 days per quarter mentioned in the survey builds up to more than one month per year - is spent conducting ineffective audits and producing documentation for compliance reports. As with many IT disciplines, finding ways to automate activity is the key to freeing time for skilled resources to be more effective. Automating the best practices of firewall compliance returns direct cost savings to the organization. With automation, organizations discover dangerous configuration changes before the business is exposed to security incidents, generate compliance reports whenever required by the regulations, and shift audit approaches to expert reviews of the security strategy more than manual reviews of firewall rules.  Seeking continuous compliance moves the business closer to the goal of integrating security into business operations with fewer deviations from compliance that can put the business at risk. Spending significant security resources to find security problems only 1.3% of the time doesn't make sense - if that is your ratio, then automating firewall management is a no brainer. Shaul Efraim http://www.tufin.com/blog/rss/blog/posts/2012/january/network-security-101-automating-for-continuous-compliance/ http://www.tufin.com/blog/rss/blog/posts/2012/january/network-security-101-automating-for-continuous-compliance/ Tue, 24 January 2012 00:00:00 Ruvi Kitov http://www.tufin.com/blog/rss/blog/posts/2011/september/tufin-launches-tss-60/ Two days ago we announced the release of the  Tufin Security Suite (TSS) version 6.0 . First off, I'd like to say that I'm very proud of the superb job done by the Products and R&D teams - I'm honored to work with such a talented group of people… This release has been a long time in the making, and is packed with "goodies" that our customers asked for. The key enhancements which people found most exciting are: Enhanced Next Generation firewall support  - TSS 6.0 contains tighter integration of NGFW into various parts of the product, and furthers our ability to build compliance rules for NGFW policies (enabling admins to specify restrictions based on applications and users). We currently support Palo Alto Networks, and plan to add more NGFW vendors soon. Enhanced Network Topology Intelligence  - we've dramatically improved our ability to automatically build a graphical map of the various network devices (firewalls, routers, switches, etc). Based on the respective routing tables and access policies, we use graph algorithms to calculate the paths between different points in the network.   Why is this a big deal? Well, there are many uses for topology intelligence within our products, but the most interesting one (in my view) is when a user requests access through a SecureChange ticket, and that access may actually span multiple network devices. This means that the firewall admin will need to make configuration changes on multiple devices. SecureChange in TSS 6.0 can use Topology Intelligence to identify exactly which devices need to be configured, and the Policy Advisor can prepare a "cookbook" of which changes should be implemented on which device, in order to complete the change request. Another cool feature of our topology graph is that it is auto-correcting: when routes change on network devices, we are aware of these changes in real-time, and re-build the network topology graph automatically. The third enhancement that's worth mentioning is our new  High Availability (HA) mode  - customers have always asked us about HA for Tufin servers, and with the advent of SecureChange, which is a critical component in the change process, IT managers expect data synchronization and the ability to fail-over during power outages, even across remote data centers. With TSS 6.0, Tufin servers can be installed in a primary/secondary HA configuration, with continous database synchronization, to ensure reliable and consistent data state following a fail-over. There are many more enhancements, which you can read about  here . Now that 6.0 was launched, we're working hard on our next release - more news on that in a few weeks… Take care, Ruvi   http://www.tufin.com/blog/rss/blog/posts/2011/september/tufin-launches-tss-60/ http://www.tufin.com/blog/rss/blog/posts/2011/september/tufin-launches-tss-60/ Tue, 13 September 2011 00:00:00 Diana Kelley http://www.tufin.com/blog/rss/blog/posts/2011/july/tufin-guest-blogger-diana-kelly-asks-again-are-your-firewalls-burning-money-(part-two)/ Think about how much your organization spends annually on firewall hardware, software licenses, and management. Now think about watching all that money washing down the drain because a single poorly implemented rule circumvented all of the other firewall-based protections. Sounds a little alarming, but if you're a firewall administrator, you know how real that possibility is. In a  previous post  we took a look at "shadow rules" and why investing in automated tools that help eliminate them can be a solid business, not to mention security investment. But eliminating redundant, outdated and ineffective rules is only part of the problem.  For many firewall administrators, the bigger challenge is handling the day-to-day requests for firewall rule changes without introducing vulnerabilities or exposure points. Firewalls aren't static sentries that are set up once and run without change for years. Most firewalls have a fluid set of rules and are frequently updated to support new services for the business. While there's nothing fundamentally wrong with change, how that change occurs can have significant security repercussions. When an admin is being pressured to make a change outside of the normal change management lifecycle and without proper risk analysis, problems occur. Consider a business unit owner that is in a rush to have a couple of ports opened on the firewall so an external software development company can set up and test their application on the company servers. Chances are the business owner doesn't know the technical reasons why these ports need to be opened or the risk associated with allowing traffic through newly opened ports, he just knows the developer said to open them.  Because the owner doesn't understand the potential risks associated with the change, he sees the firewall rules as nothing more than an annoying and unnecessary impediment to getting his application running. This lack of understanding about how firewalls work can lead to requests for risky rule changes. For example, sometimes the application or business owner doesn't know which ports should be opened or which services or servers the should be opened for, so they ask for overly permissive rules with ANY that allow all traffic, good and bad, through. Some permissive requests are allowed for a short time for testing purposes and are supposed to expire after the test window. Unfortunately, setting and managing rule expiration dates on multiple firewalls and routers is no easy task. So it's not uncommon to find permissive rules that were supposed to expire weeks or months earlier, still in effect well after the testing period is complete. If the business unit owner works in an organization with a robust change management lifecycle, he will need to submit the change request and follow certain procedures to have the change approved and implemented. A typical change management process includes writing up the business justification for the change request, a technical assessment of direct or indirect impacts from the change, and an analysis of the risk trade-offs. For example some of the questions that may be answered during this process include: Will the change cause the company to be in violation of a legal or industry mandate? Will the change put other systems in the organization at security or business continuity risk? Can the business requirement be met with an alternative solution? Following a set process, like the one outlined above, gives firewall admins time to participate in the process and perform risk analysis before a change is accepted. Unfortunately this process goes awry in two very common ways: 1) The admins are not included in the risk assessment phase or 2) they are not given enough time to complete a thorough analysis. Worst case, for the sake of speed - the change is approved without any kind of formal process and the firewall admins must implement them immediately. Arguably, one of the main reasons admins and risk analysts are "left out" of the risk assessment phase is because their analysis takes too long or their recommendations are seen as too restrictive to the business. So how can a firewall admins speed up their decision time, provide better insight into corporate risks associated with firewall configuration changes, and get back into the assessment phase? First, security professionals need some way to model potential changes to the network environment before implementing them. This goes well beyond firewalls because a network is comprised of multiple layers of systems and services, but firewalls are the first line of defense. Any time a change is proposed, be it a new service coming online, a change to a different database platform, or a set of firewall rules to allow for communications to and from these new services risk assessment should be completed. Having tools to help with this kind of modeling speeds up the process and may catch things a human couldn't on their own. Tools and techniques here include network topology and mapping, penetration testing and scanning, log analysis, and the risk consoles of IT-GRC solutions.  For firewalls specifically, administrators can use a tool that parses the existing rule set against one with the proposed change and identifies potential areas for exposure or if any of the new rules causes an inadvertent override of existing ones. Bringing all of this information together into a single report, helps security and firewall professionals assess risks associated with proposed changes more quickly and accurately. To make this information even more valuable, translate the risk into business friendly terms before presenting them back to executives. While the statement  "opening port 1025 is not advised because it's not in official assigned use with IANA and has been associated with RPC vulns in the past"  sounds like "dolphin" to most people, saying   "if we open that port, an external attacker could take control of our servers"  is pretty easy for all of us to grasp. Another way to speed up the risk assessment process, without sacrificing security, is to learn how changes impact the system over time. The first time a request is made to open a port like 1025 a long evaluation may be in order. But if the assessment has already been completed, when the second (or third, or fourth) request to open that port comes in, the response time can be reduced but re-using relevant data from the previous assessments. By keeping a record of known and fully vetted requests for future reference, efficiency and cost-reduction are realized through re-use of existing knowledge rather than by skipping the knowledge gathering step altogether. http://www.tufin.com/blog/rss/blog/posts/2011/july/tufin-guest-blogger-diana-kelly-asks-again-are-your-firewalls-burning-money-(part-two)/ http://www.tufin.com/blog/rss/blog/posts/2011/july/tufin-guest-blogger-diana-kelly-asks-again-are-your-firewalls-burning-money-(part-two)/ Wed, 13 July 2011 00:00:00 Eric Ogren http://www.tufin.com/blog/rss/blog/posts/2011/july/“kick-it-up-a-notch-–-virtualization-accelerates-firewall-rule-change-requests”/ The shift to virtualization, with most organizations virtualizing more than 30% of their applications, challenges the means by which security teams implement firewall-based foundational controls. Organizations are embracing virtualization for obvious cost savings benefits when applications share server and infrastructure resources. In fact, many enterprises continue to re-architect networks to consolidate data centers, applications and IT services. For instance, the rapid provisioning of applications - running in a matter of minutes on a virtual server for a task that would take weeks with physical architectures - necessitates a rapid evolution in the security lifecycle management of firewall rules. Virtualization forces firewall rules to change more dynamically than ever before with applications spinning up and being decommissioned upon user demand. The firewall must now manage additional complexities in a virtual environment to quickly accommodate connectivity and access requests at the speed of business without creating security holes. Here are a few ways that firewall rules management is helping to secure virtual data centers: Streamline firewall rules management workflow by automating the checking of compliance rules before a manual review. Security and network teams can be overwhelmed with requests for modifications to the firewall rules sets. Firewall rules management can automatically validate that requested changes do not violate corporate security policy or compliance mandates. In some cases the manual review overhead can be eliminated with a "compliance acid test" saving time and money. Reduce the complexity of managing rules as firewalls are consolidated into virtualized servers. Organizations are placing multiple instances of firewalls on individual virtual servers, adding significant complexity to firewall rules management. For example, organizations deploying Check Point VSX need to deploy rules changes while evolving the virtual architecture, and must manage multiple firewall rule sets existing in a single security device. This is a new challenge for security teams - having the right tool for keeping effective firewall rules within a sophisticated device, tracking and auditing changes, and managing workflows associated with firewall lifecycles is critically important. Although organizations prefer to keep applications within a data center to avoid changing IP address assignments, the use of VMware vMotion across data centers and geographies - perhaps to support a mobile work force using smartphones and tablets - requires consistent firewall rules to avoid disruptions in business. Firewall lifecycle management can help security teams ensure that users can access applications, and that applications do not fall out of compliance, as capabilities such as vMotion shift applications. This capability becomes particularly important in high availability and disaster recovery scenarios. Security is still catching up to the demands of virtualization. Firewalls are particularly vulnerable in virtual environments because the speed of change is accelerated over traditional physical architectures, leading to increased risk of business disruptions and security incidents. Enterprises embracing virtualization can save themselves a lot of pain by checking out firewall rules management products.   http://www.tufin.com/blog/rss/blog/posts/2011/july/“kick-it-up-a-notch-–-virtualization-accelerates-firewall-rule-change-requests”/ http://www.tufin.com/blog/rss/blog/posts/2011/july/“kick-it-up-a-notch-–-virtualization-accelerates-firewall-rule-change-requests”/ Wed, 13 July 2011 00:00:00 Diana Kelley http://www.tufin.com/blog/rss/blog/posts/2011/july/blogger-diana-kelley-asks-“are-your-firewalls-burning-money”/ As firewall admins and installers (for history buffs, I was a firewall admin and also a TIS Gauntlet firewall installer back in the 90s), we know how much time it can take to write a truly effective list of firewall rules - and to confirm that no previous rule overshadows, contradicts, or renders ineffective a rule further down the list. But if you're trying to explain to a manager or executive why the process is so tricky - and if done improperly can lead to large, unexpected exposures - you might be met with blank stares.  Even if a manager does have an understanding of the issue, many assume that the problem has been solved by the firewall manufacturers.  Surely this can't still be an issue in 2011? Well, it is.    Why?  Oftentimes, it is because it is surprisingly difficult to translate the implications to the folks earmarking funds to solve the problem.  While non-security professionals can connect to the idea of layered security, it's easy for them to miss the big picture when it comes to the complexities of firewall rules. Personal, physical layered security might look like this: a person with valuables lives in a gated community, has an alarm system on their house, and keeps very high value items in a locked safe.  Security controls may go like this: everyone who lives in the gated community and their trusted family group members have access to through the gate. For each house, only members of that household have access to the alarm code. And the wall safe's unlock code is known only by the owner of the house and one other person. This set-up sounds very secure and orderly doesn't it? Now consider a scenario where a person who gets through the gates creates an override situation on all the other security layers. Anyone that passes the gate as an authorized user can get into any house in the community, because the alarms are no longer active, and these same people can access the valuables in all the wall safes because the locks are automatically unlocked for authorized entrants that passed the gate. Sound a little crazy? Welcome to the world of firewall shadow rules. In order to manage firewall rules in a risk reductive manner, admins need to invest time or money in manually auditing and reviewing configurations in a 3 rd  party audit and analysis tool. Manual time can seem "free" to an organization because full time employees can absorb some of that cost by working extra hours yet still receiving their regular salaries. Of course the real cost isn't "free" at all - at some point, an employee will have maxed out their available work hours and a new headcount will be required to cover the extra work. Weighing the cost of additional headcount against the cost of an automated tool can be a compelling argument for a purchase, but first that argument needs to be presented to executives in a manner that makes sense to them. Chances are most executives don't want to have to learn about the intricacies of firewall management, they just want to know what the data and business risks can cost the business. Our story about the gated community and the house safes is a good possible first pass at an explanation for executives, but to make it real those concepts need to be extended to more realistic business scenarios. You've probably got some great stories of your own, but to get us started here's an example. The expensive perimeter firewalls have been configured with a highly granular series of rule sets to block access to an internal HR application that houses salary and health information of employees so that only authorized remote employees and critical services can access it. Problem is, there's a rule higher up in the firewall rule set and overrides all of the subsequent complex rules and allows any system access to that HR app. Manual review didn't catch it and all the time spent creating the complex rules was wasted, as well as potentially incurring further expense down the road (a failed PCI audit, for example). Will that resonate with your executives? Having executives on board with the importance of proper firewall configuration is a huge step. Now let's return to the headcount issue and quantify the amount of time it takes to actually get the rules right. How many firewalls are there in your organization? How much time has been spent in the past to ensure the rules are written well and working as expected? How many hours are spent reviewing configurations and analyzing risk each time a business unit owner asks for a change to the rules so that a new application or service can be put into production? And how many times are changes requested per month or per year? Calculate out the number of hours and the cost of those hours to get a firm number. Now calculate how much of this time could be saved if an automated tool were in use.  Subtract the cost of hours saved from the cost of the tool and create a savings sheet for a 1-5 year time frame. Another way to demonstrate ongoing value of investing in automation could be to measure the accuracy of rule changes using an automated tool v. a manual review, or as a troubleshooting tool for firewall related incident or outages. If the tool will save significant money for the company, and reduce risks from misconfiguration in the process, it shouldn't be too hard to convince executives that it's a worthwhile investment. In the second part of this two-part post we'll take a look at the change management and risk analysis costs associated with firewall configuration and management. Diana Kelley is 20 year veteran in the field of networking and information security. She is a founding partner at SecurityCurve,  previously she was VP and Service Director for SRMS at Burton Group, a Manager in KPMG Financial Services consulting and a TIS certified Gauntlet firewall installer.  She speaks often on the subject of data and network security and is a frequent contributor to SearchSecurity.techtarget.com. http://www.tufin.com/blog/rss/blog/posts/2011/july/blogger-diana-kelley-asks-“are-your-firewalls-burning-money”/ http://www.tufin.com/blog/rss/blog/posts/2011/july/blogger-diana-kelley-asks-“are-your-firewalls-burning-money”/ Fri, 01 July 2011 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2011/march/firewall-expert-tip-10-–-creating-a-secure,-yet-manageable-firewall-policy-for-a-large-company/ When it comes to network security policy, there often seems to be a direct tradeoff between security and maintainability.  I've found this to be untrue. Even in large organizations, security policies can be easy to maintain if you follow some best practices that will ensure that they remain clear, intuitive and well-organized as they grow. Ready for Change Thebusiness requires on-going changes to connectivity. Making these changes is the responsibility of firewall administrators.Your goal as the architect of the security policy is to make it easy for the administrators to find the relevant rule - or add new ones when needed - so that they can provide fast and accurate service.  Here are a few guidelines for architecting a policy for maintainability: Provide clear documentation for each rule and network object so that anybody can understand what they are for. You can do this with the vendor's documentation capabilities and if you have Tufin SecureTrack , you can use Rule Documentation to add descriptions to individual rules, or groups of rules. Avoid using the same rules and network objects for multiple purposes. Create another rule or object so you don't wind up with rules and objects that do everything, but are insecure and impossible to maintain. You can find and tighten overly permissive rules with SecureTrack's  Automatic Policy Generator (APG) . Group rules per business need and document them with a section title - supported by some vendors. Easy to Troubleshoot for Connectivity Problems When something goes wrong, the firewall is often first to be blamed. To make sure that you can determine whether the firewall is the source of a problem, insist on trouble tickets with precise information, such as "Joe's PC cannot access CRM over HTTP." If you have a clear problem definition, you can quickly determine which firewalls are involved and find out if they are blocking traffic by analyzing logs or the security policy. With SecureTrack , you can check this quickly with a Policy Analysis query. It identifies relevant firewalls and rules automatically. Easy to Reverse Changes when Necessary When the security policy is responsible for an outage or is blocking connectivity, you should be able to quickly determine when, why and how the policy was broken and reverse the relevant changes. You can do this if you maintain an easy-to-read audit trail of all policy changes with full personal accountability.  It's difficult to maintain an accurate audit trail without an automated change management solution . If you do go for an automated solution, make sure that it supports real-time policy tracking , which will ensure that all changes are recorded along with the name of the person who made them. Self-Documenting and Usable by All The firewall or ACL policy should contain all of the information that is needed to manage it. Do not allow anyone to introduce undocumented changes, not even temporarily. You can challenge the team periodically by asking "what does this rule do?" or "show me the CRM rules."  Managing the policy must not depend on any one person's private knowledge. Easy to Learn and Understand When a new administrator comes on board, you should be able to teach him the policy quickly. You should be able to say "this is our policy structure" and "this is our process for changing policies" rather than "this rule does this and this rule does that…" Consistent across Firewalls, even from Different Vendor Your policy design should be consistent across the environment. Keep in mind that even if you have a single policy today you may have many more in the future. Firewalls from other vendors may appear because of business requirements such as mergers and acquisitions, cost reductions that dictate a vendor switch or emerging technologies (e.g., next-generation firewalls).  SecureTrack provides a central, unified view for all leading firewalls . You can use SecureTrack to assist daily firewall operations as well as enforce security policies and business continuity policies across your firewalls. Even better, you can implement a Security Change Automation system such as SecureChange Workflow to proactively implement corporate policies across all of the network devices in your organization. Well Documented Every rule and important object should be documented.Maintain policy sections with clear names where possible.For every policy change, put the relevant ticket ID in the comments field and use a standard convention.Some people like to maintain an object naming-convention, for example: host-10.0.1.30 or net-10.0.1.0.  SecureTrack ticketing integration can link ticket IDs in rules and objects to the originating request in any web-based ticketing system. You can correlate a ticket ID with specific changes, even across firewalls. The Best Practices report supports enforcement of object naming conventions. Justified by the Business Every permissive rule should be there for a reason - or it is just a security compromise. Don't allow over-permissive rules, even temporarily (unless you have a well defined procedure to correct them later). Put time restrictions on temporary access flows (different vendors have different mechanisms for this such as Time Objects in Check Point or Rule Expiration in Cisco).Periodically remove stale rules and objects. You will need some mechanism to identify these, such as SecureTracks' Rule and Object usage report , as wellas documentation of the business owners so that you can contact them and verify that the access is no longer needed before removing it. Some vendors enable you to document business and technical owners for rules, and if not, you can do this with SecureTrack rule documentation . A Manifestation of High-Level Security Policy Last but not least, your firewall "policy" is not the security policy, it is only a manifestation of a part of it (other parts may be related to end-point security,physical security etc.). Make sure that your firewall policies follow a well-defined security policy, such as, for example, a zone-based white list policy. Be prepared to prove compliance at all times. If you have an automated solution like SecureTrack , define your corporate security policy (black or white list) along with real-time alerts so that you will know about violations immediately. In addition, I recommend maintaining a written Guidelines and Procedures document that explains the policy structure, documentation standards, naming conventions and procedures for change policies. Share your recommendations for keeping large security policies under control. Reuven http://www.tufin.com/blog/rss/blog/posts/2011/march/firewall-expert-tip-10-–-creating-a-secure,-yet-manageable-firewall-policy-for-a-large-company/ http://www.tufin.com/blog/rss/blog/posts/2011/march/firewall-expert-tip-10-–-creating-a-secure,-yet-manageable-firewall-policy-for-a-large-company/ Wed, 30 March 2011 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2011/february/the-automatic-policy-generator-gets-a-new-look/ Hi again. In this post I'll discuss the new and enhanced automatic policy generator (APG) in TSS 5.3 which was released today. We first conceived the idea for the APG about three years ago. You can see a blog post that I wrote about it here in June 2009. The general idea of the APG is to clean up overly permissive firewall rules by inspecting the traffic that flows through them and generating a more refined set of rules to replace the original one. While the original APG had a command-line interface, the enhanced version in TSS 5.3 now has a graphical user interface. The APG shows you how permissive each one of your rules is. This assists in identifying rules that need to be tightened up. The permissiveness score ranges from 1 for a host to host rule with a single port to 100 for an Any-Any-Any rule. Next, the APG reads the traffic logs and suggests rules to replace the original one. It shows you how much you're going to gain in terms of permissiveness or, in other words, how much more secure the suggested rule base is compared to the original one. But, as you know, there's no such thing as a free lunch. Reducing permissiveness has its price, and the price is - increasing the number of rules. The APG visualizes this tradeoff as an interactive graph - you can click any point on this graph and see the corresponding rule base.  Once you have the new rule base, you can continue to edit it in SeureTrack and when you're happy with the result, you can export it to a CSV file. Basing the design on actual traffic presents a breakthrough in the way firewall policies are built and designed. We are very proud of this achievement which is now also patent pending. Looking forward for your feedback. Reuven http://www.tufin.com/blog/rss/blog/posts/2011/february/the-automatic-policy-generator-gets-a-new-look/ http://www.tufin.com/blog/rss/blog/posts/2011/february/the-automatic-policy-generator-gets-a-new-look/ Tue, 22 February 2011 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2011/february/tss-53-and-next-generation-firewalls/ Hi, We're here at the RSA show in San Francisco this week to present our exciting new features in the Tufin Security Suite (TSS) 5.3 release. This new version includes several major enhancements to our solutions: Support for the Palo Alto Networks Next-Generation Firewall Enhanced Automatic Policy Generator Support for PCI-DSS 2.0 The Zone Manager In this post, I'll give several examples for how TSS 5.3 delivers operations management and auditing solutions for Next-Generation firewalls. Next-Generation firewalls support two new dimensions of security that were traditionally not enforced by firewalls: user access and application access. This extension to the firewall functionality is so natural and useful that it is bound to become the standard for all firewalls. That's why, in 2010, we've seen an increase in demand for Next-Generation firewalls, as more and more of our users were asking us to add support for Palo Alto Networks. TSS 5.3 now supports this new firewall type. It provides monitoring, alerting and reporting for policy changes including changes to application definitions which Palo Alto Networks delivers through automatic updates. This means that you'll be able to get notifications and reports every time an application, or application group (or filter), is modified, either manually or automatically. The Palo Alto Networks firewalls can also be analyzed using interactive policy analysis queries. This gives our users the ability to trouble-shoot connectivity problems and design policy changes using any of the rule fields: source, destination, service, user and application! For example, if John opened a helpdesk ticket reporting broken access to the CRM, you can run a query to see which rules are blocking this access. Compliance policies are now also user and application-aware, meaning that you can set up black-lists, white-lists and business continuity policies to protect your environment from dangerous changes and to perform firewall audits. For example, you can now generate a PDF report of all the rules allowing Collaboration applications across all of your firewalls. I'll follow up with posts about the other TSS 5.3 features during the week. Live from RSA - San Francisco, Reuven http://www.tufin.com/blog/rss/blog/posts/2011/february/tss-53-and-next-generation-firewalls/ http://www.tufin.com/blog/rss/blog/posts/2011/february/tss-53-and-next-generation-firewalls/ Wed, 16 February 2011 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2011/january/tufin-firewall-expert-tip-9-the-lifecycle-of-a-firewall-rule/ In the infographic below we've summarized the (long and sometimes tortuous) life of a firewall policy rule. Firewall rules are born and modified as a result of access requests from users or IT projects. And over time, they become irrelevant - because applications, services and networks change, and users leave. http://www.tufin.com/blog/rss/blog/posts/2011/january/tufin-firewall-expert-tip-9-the-lifecycle-of-a-firewall-rule/ http://www.tufin.com/blog/rss/blog/posts/2011/january/tufin-firewall-expert-tip-9-the-lifecycle-of-a-firewall-rule/ Thu, 13 January 2011 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2010/november/prepare-your-network-for-black-friday,-cyber-monday-and-the-christmas-shopping-season/ It starts in a few days - crowds will go shopping, transaction rates will reach new peaks and your web servers will be loaded to maximum capacity. Just a little bit more, and they will fall over - causing downtime and disrupting business. What can you do to avoid this scenario? First, start monitoring now! The firewall is ideally placed for monitoring connection rates. Make sure that logs are being generated. If you are not recording firewall performance stats, turn it on now- before you need it. Next, start looking for anything that can cause an interruption of service due to resource exhaustion.  What is your firewall connection table limit? If it was 25,000 last year, should it be a little higher this year? Take a look at what your peak was last year and what your peak has been so far this year. Plan for somewhere between 20% and 200% depending on your business model. You want to make sure you don't hit your max connections at this time of year. Often we set this number low enough to stop a denial-of-service, but at this time of year we are expecting that sudden burst of connections. Make sure you print out some hard copies of performance trends from last year. It is much easier if you already have them handy when you are trying to understand this year's trend. Also take a look at all of your disk drives. Logically, do you have plenty of space?  Don't forget to physically walk to your firewalls and make sure there are no failed drives with the little red lights on.  With firewalls tucked away in datacenters, and drives in RAID, we sometimes forget to look for faults on devices, like a failed drive in a RAID mirror set. One of our users explained the following technique: Monitor the connection rate through the firewall Get alerted when certain thresholds are reached and decide what to do based on the trends Monitoring Firewall Connections with SecureTrack If you use SecureTrack, it can monitor firewall connections using the firewall OS monitoring facility. SecureTrack actually monitors a variety of parameters such as CPU Usage, Memory, Packets (accepted, dropped etc.), Processes and Disk space. You can also define thresholds and receive e-mail alerts that include the recent trend: When a connection threshold is reached, you can perform additional analysis to determine the cause of traffic. Run a rule and object usage report to pin-point the exact rules, networks and services that cause the high connection rate. We're interested in your feedback - what anti-overload techniques do you use? Michael and Reuven http://www.tufin.com/blog/rss/blog/posts/2010/november/prepare-your-network-for-black-friday,-cyber-monday-and-the-christmas-shopping-season/ http://www.tufin.com/blog/rss/blog/posts/2010/november/prepare-your-network-for-black-friday,-cyber-monday-and-the-christmas-shopping-season/ Tue, 23 November 2010 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2010/november/tufin-firewall-expert-tip-8-–-how-to-perform-a-firewall-audit/ In my last post I talked about preparing for a firewall audit and all the control points that an auditor will want to check in order to understand if your firewall operations are auditable and repeatable. Today I want to focus on two parts of the firewall audit: the review of the change process, and the review of the rule base.  In my experience, these two steps are the most important. I'll go over many of the technical details you need to check if you are pre-auditing your firewall before the audit team arrives, or if it is your job to audit the firewall. Auditing the Change Process The first technical step in a firewall audit is normally an examination of the firewall change process. The goal of this step is to make sure that requested changes were properly approved, implemented and documented.  You can accomplish this in a few different ways - depending on whether you have a tool to assist you or you are doing it manually. You will need to pull, at random, around 10 change requests since the last audit. The basic questions you should be asking when you audit a firewall change are: Is the requester documented, and is s/he authorized to make firewall change requests? Is the business reason for the change documented? Are there proper reviewer and approval signatures (electronic or physical)? Were the approvals recorded before the change was implemented? Are the approvers all authorized to approve firewall changes (you will need to ask for a list of authorized individuals)? Are the changes well-documented in the change ticket? Is there documentation of risk analysis for each change? Is there documentation of the change window and/or install date for each change? Is there an expiration date for the change? If you are doing this manually, the first thing you need to do is match each of the changes up with a firewall device and with a policy. Now match the change requests up with the firewall rule(s) that implemented the requested traffic. Already stumped?  Then you know where you need to improve.  The comment on each rule should have at least 2 pieces of data: the change ID of the request and the initials of the engineer who implemented the change. There are more automated ways to do this.  For example, Tufin SecureTrack shows you who added the rule and when, as well as if s/he added anything else to the policy at the same time. You can put the change ticket number in the comment field, so that the rule will have a hyperlink back to the change ticket to simplify looking up the audit trail.  You can even run a rule history report over time to see how this rule has changed with other change tickets since it was implemented.  The most complete solution would be to use a security change automation product like SecureChange Workflow which will show the rule request along with audit signoff, risk analysis, and implementation into the rule-base, so that the whole lifecycle from request to implementation is documented and auditable. Auditing the Firewall Rule Base The second technical step in an audit is usually a review of the firewall rulebase (also called a policy). The methodology for this step varies widely among auditors because it has traditionally been difficult to do and heavily technology-dependent. For each of these questions you should have a ranking based on the type of firewall and it's placement in your infrastructure. For example, a firewall not connected to the Internet does not have the same risk as one that is connected to the internet; internal firewalls tend to be more permissive than external firewalls. The first questions that should be asked about the rulebase are related to basic policy maintenance and good design practices that grant minimal access for each device.  To answer these questions, you need to look at each rule in your rulebase and as well as a year's worth of logs, which will tell you which rules are being used.  This has always been a lengthy manual process until recently, with the arrival of tools like SecureTrack that can be used to answer these questions programmatically and automatically. How many rules does the policy have? How many did it have at last audit? Last year? Are there any uncommented rules? Are there any redundant rules that should be removed? Are there any rules that are no longer used? Are there any services in the rules that are no longer used? Are there any groups or networks in the rules that are no longer used? Are there any firewall rules with ANY in three fields (source, destination, service/protocol) and a permissive action? Are there any rules with ANY in two fields and a permissive action? Are there any rules with ANY in one field and a permissive action? Are there any overly permissive rules: rules with more than 1000 IP addresses allowed in the source or destination? (you might want a number other than 1000, like 10,000, or 500) The second list of questions that should be asked about a rulebase concern risk and compliance. These rules are more technically challenging to answer.  You must understand the technology of your firewall to understand what traffic is actually passed by each rule, and if there is a group of services called "allowed services," then which ports and protocols actually pass though that rule.  The advantage of a tool like SecureTrack is that it can understand each security policy and automate deep technology questions like these. SecureTrack can answer all of these questions with the Security Risk Report and Customized Compliance Checks: Are there any rules that violate our corporate security policy? Are there any rules that allow risky services inbound from the Internet?  While you may have a different list of what is considered "risky" for your company, most start with protocols that pass login credentials in the clear like telnet, ftp, pop, imap, http, netbios, etc. Are there any rules that allow risky services outbound to the internet? Are there any rules that allow direct traffic from the Internet to the Internal network (not the DMZ)? Are there any rules that allow traffic from the Internet to sensitive servers, networks, devices or databases? There you have it, my top two steps for a firewall audit.  If you take the time to master these two processes you will find that it is much easier to pass firewall audits.  These questions are much easier to answer with the help of automation technology. And having responded to hundreds of firewall audits, I'm quite passionate about making sure SecureTrack has the knowledge to help administrators answer difficult audit questions quickly. Michael http://www.tufin.com/blog/rss/blog/posts/2010/november/tufin-firewall-expert-tip-8-–-how-to-perform-a-firewall-audit/ http://www.tufin.com/blog/rss/blog/posts/2010/november/tufin-firewall-expert-tip-8-–-how-to-perform-a-firewall-audit/ Tue, 02 November 2010 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2010/october/tufin-wins-2nd-place-at-the-deloitte-tech-fast-50-competition/ Today, Tufin was announced as the 2nd place winner in the Deloitte Tech Fast 50 competition in Israel. The competing companies' revenues are compared over the past five years, and they all had to be hi-tech companies. Our revenue growth over this period was %5359 (x53 revenue growth over five years). Although the announcement in itself has no actual impact on our business, it's very gratifying to receive recognition for our achievements. We have very rare opportunities to stop and reflect on our progress, especially at the rapid pace of business expansion and innovation which our industry is experiencing. Doing so well in this competition is a tribute to all of the Tufin employees and partners, who work very hard every day to deliver the best possible security management products to our 600+ customers. We would never have been able to reach this success without their dedication and true customer focus. Thank you all! Ruvi http://www.tufin.com/blog/rss/blog/posts/2010/october/tufin-wins-2nd-place-at-the-deloitte-tech-fast-50-competition/ http://www.tufin.com/blog/rss/blog/posts/2010/october/tufin-wins-2nd-place-at-the-deloitte-tech-fast-50-competition/ Mon, 18 October 2010 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2010/september/tufin-firewall-expert-tip-7-–-preparing-for-a-firewall-audit/ Network security audits are getting a lot of coverage these days thanks to standards like SOX, PCI-DSS, and HIPAA. Even if you don't need to comply with any of those standards - yet - business relationships with partners or customers may require you to show that your network is secure.  However, beyond compliance requirements, firewall audits are best practice for a very good reason. They increase your chances of catching weaknesses in your network security posture and finding places your policies need to be adapted. They also help prove you have been doing your due diligence in reviewing your security controls and policy controls, should you ever need to respond to a lawsuit, breach or regulatory issue that call your security standards into question. To help you better understand the depth and breadth of a full firewall audit, we compiled the steps of a typical audit process. In our next tip, we'll take a closer look at several of these areas and dive into the technical details of the firewall policy audit. The main steps of a firewall audit: 1. Review the company's firewall security policy If you're going to audit something, you need to know what you're looking for. Your company should have a written set of security guidelines that sum up policy for firewalls and related security infrastructure. If you need to comply with industry, government or regulatory standards, review those as well.  Are those requirements reflected in your corporate security guidelines? 2. Review the company's firewall operations policies Your company should have defined the accepted procedures for firewall management including changes, approvals, accountability, and record keeping. Your company should have defined procedures for responding to firewall security incidents. What is the escalation procedure? Who is authorized to respond? How do you coordinate with law enforcement? How is the impact of an attack and its response coordinated with the business and communicated to customers and other relevant stakeholders? 3. Review the firewall administrators who are authorized to make changes Are they all still employees of the company? Are they all still on the firewall management team? Are they all properly trained in the technology? Do they receive ongoing technical training? Do you have a procedure for identifying and removing administrators who have either left the organization or no longer have firewall access rights? Is it connected to HR? 4. Review the firewall change procedures How are changes managed? What is the procedure that is used to receive requests, track them, approve them and verify completion? Who signs off on firewall changes?  Is there a formal process in place for this?  Is an audit trail maintained? How are unauthorized changes detected? Are all actual changes on the firewall captured? Is there a complete audit trail?  Can you demonstrate accountability for every change? Collect a sample of firewall change requests and verify that they were implemented. Was the company's approval policy maintained? Are the changes documented is in the firewall rule base? 5. Review the firewall system design Is the firewall technology current?  Does your organization have an established, documented procedure for technology upgrades? Have all of the latest software versions been installed? Are patches applied regularly?  It does not need to be bleeding edge but 3 years is too long! Does the firewall rule base adequately protect the organization?  If you are not sure, refer to the corporate security guidelines. Are the controls specified in the written Policy adequately enforced? Is it clear to you exactly HOW they are being enforced? 6. Review the firewall review process Is the rule base reviewed at least once a year, and preferably more often- ideally once a quarter? Are redundant rules identified and removed from the rule base? Are unused rules and objects identified and removed from the rule base? Are overly permissive rules flagged for investigation? Are risky traffic flows identified? In our next tip, we'll look at the practical side of conducting a firewall audit and see how automated tools can help you to do them more quickly and efficiently. If there is something you think we left out, or if you have suggestions on how to perform firewall audits, we'd like to hear from you before our next tip. Michael http://www.tufin.com/blog/rss/blog/posts/2010/september/tufin-firewall-expert-tip-7-–-preparing-for-a-firewall-audit/ http://www.tufin.com/blog/rss/blog/posts/2010/september/tufin-firewall-expert-tip-7-–-preparing-for-a-firewall-audit/ Tue, 07 September 2010 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2010/july/tufin-firewall-expert-tip-6-–-how-to-clean-up-a-firewall-rulebase/ Over time, firewall rulebases tend to become large and complicated. They often include rules that are either partially or completely unused, expired or shadowed. The problem gets worse if there have been multiple administrators making changes or if there are many firewalls in your organization. When the rule base gets big and tangled, it starts to affect firewall performance.  It is difficult to maintain, and it can conceal genuine security risks. And standards such as PCI-DSS require clean-up of unused rules and objects. With some help from our customers, I've put together a list of best practices for cleaning up a firewall (or router) rule base. You can do all of these checks on your own, but if you have Tufin SecureTrack you can run most of them automatically. Delete fully shadowed rules that are effectively useless. If you have SecureTrack, these are detected by the Rule and Object Usage report. Delete expired and unused rules and objects . All of these are detected by the Rule and Object Usage and the Expired Rules reports. Remove unused connections - specific source/destination/service routes that are not in use. You can detect those using the Automatic Policy Generator to analyze traffic patterns. Enforce object naming conventions that make the rule base easy to understand. For example, use a consistent format such as host_name_IP for hosts. This is an option in the SecureTrack Best Practices report. Delete old and unused policies . Check Point and some other vendors allow you to keep multiple rule bases. This is another test in the Best Practices report. Remove duplicate objects , for example, a service or network host that is defined twice with different names.  The Best Practices Report can identify these. Reduce shadowing as much as possible. You can detect partially shadowed rules with Policy Analysis. Break up long rule sections into readable chunks of no more than 20 rules. This too can be checked with the Best Practices report. Document rules, objects and policy revisions - for future reference. You can do this with some vendor tools. In SecureTrack, you can document revisions, for instance, to indicate when an audit was performed. You can also link policy changes to tickets from your help desk to store additional information about the requestor, approver, etc. You can enforce a standard for rule documentation with the Rule Comments Format test in the Best Practices report. Last but not least, some of your most important security checks also help you maintain a clean, compact rule base. If you use SecureTrack, try these: Tighten up permissive rules : Run the Rule Volume Report (under /tools on the SecureTrack Web GUI) to detect rules that are too open and tighten them up with the Automatic Policy Generator . Define a zone-based compliance policy and check it by running an audit report. Identify and reduce insecure rules using the Best Practices report, the Security Risk Report, and the PCI-DSS report if it is relevant for your organization. Optimize performance. See my previous posts: Tufin Firewall Expert Tip #4: Vendor and model-specific tips for optimizing firewall performance and Tufin Firewall Expert Tip #3: Best practices for optimizing firewall performance . I'm putting together a vendor-specific list of suggestions and if you have any, I'd like to hear from you. Reuven http://www.tufin.com/blog/rss/blog/posts/2010/july/tufin-firewall-expert-tip-6-–-how-to-clean-up-a-firewall-rulebase/ http://www.tufin.com/blog/rss/blog/posts/2010/july/tufin-firewall-expert-tip-6-–-how-to-clean-up-a-firewall-rulebase/ Mon, 19 July 2010 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2010/april/business-processes-and-lego/ As a boy I loved Lego. I'd use the red and green and white bricks that, in those days, came in just a few shapes to construct houses, ships, cars and stairways that lead nowhere. It was all about fun and imagination. Last week, I was at the Check Point experience in London where I was demonstrating our workflow solution. It was a real delight meeting you out there and discussing our vision in light of your invaluable real-world experience (the bar was also not bad). It was during the 1st day that I suddenly realized the analogy between our approach and Lego and how important it is in providing a good solution. After a couple years of presenting our solution to security people from over one hundred organizations world-wide, I came to realize that there is no such thing as a standard process for managing changes to the security policy. While one organization starts off with an access request which is then approved by a line manager, another may first want to design the change. Some want to allow requesters to specify the target firewalls while others keep them strictly within the domain of the firewall operations group. Not to mention the gazillion types of forms I have seen out there. Of course, it would be easier if we could say "here's how you should be working" and provide one ideal workflow but things just don't work like that. Every organization has developed processes that match their needs and organizational structures and policies. Beyond technical constraints there are also social and political factors that have shaped these processes and they cannot be modified easily. So instead of a single rigid process we chose to provide small building blocks that can be compiled into the organizational processes, things like: Permissions and roles Users and groups Workflows that are composed of configurable steps Forms that consist of fields such as input fields and drop down lists Application flows (the requested access paths) that can change their appearance to match the needs of users with different roles Dynamic yet controllable workflows so that users have flexibility within a fixed framework This Lego approach makes our solution effective in a variety of environments with differing processes including ones we haven't even seen or anticipated. Now I'm doing real Lego again with my daughters but this time its princesses and castles instead of cars and ships. Yep, it's all about fun and imagination. Reuven. http://www.tufin.com/blog/rss/blog/posts/2010/april/business-processes-and-lego/ http://www.tufin.com/blog/rss/blog/posts/2010/april/business-processes-and-lego/ Thu, 22 April 2010 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2010/march/firewall-policy-management-webcast-with-gartners-greg-young/ We recently had a chance to catch up with Greg Young , Gartner's research VP on Firewalls, and discuss the Firewall Policy Management market . Greg spoke about several topics: Why has firewall policy mgmt become a challenge for companies today? How effectively are companies handling firewall auditing and compliance requirements? What can companies do to manage their network security operations more efficiently? How can automated solutions be used to manage risk? Are these issues also relevant for other parts of the network infrastructure? What are the advantages of using business process automation for security change requests? What is the role of firewall policy management, auditing and change automation solutions for MSSPs? The result is a very interesting (IMHO) 34 minute video , with Greg talking about the topics listed above, as well as a segment featuring yours truly, sharing Tufin's vision and thoughts on this market. http://www.tufin.com/blog/rss/blog/posts/2010/march/firewall-policy-management-webcast-with-gartners-greg-young/ http://www.tufin.com/blog/rss/blog/posts/2010/march/firewall-policy-management-webcast-with-gartners-greg-young/ Mon, 29 March 2010 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2010/march/tufin-firewall-expert-tip-5-nasty-configuration-mistakes-how-to-avoid-them-and-how-to-recover/ Ongoing changes to network and security device configuration are unavoidable and necessary for business. But they are also risky. They can have unexpected consequences - from service interruptions to performance degradation and even downtime. How can you reduce the risk associated with configuration changes? Here is a 3-tier strategy: 1. Reduce the likelihood of configuration errors: Monitor and review changes Establish change procedures and processes Establish a test plan for all changes 2. Detect problems as early as possible: Monitor the environment Listen to your users 3. Prepare for a fast recovery if something goes wrong: Maintain accessible, actionable audit information Establish standard recovery procedures Finally, implementing solutions that can automate error-prone, repetitive tasks and can maintain vigilance 24 hours a day goes a long way to preventing, and recovering from, human configuration errors. Monitor and review changes Even if they look simple, all configuration changes should be monitored and reviewed. For example, suppose you're adding a host to a network group in order to provide access, and you are unaware that the same group is used in a different place to block traffic. Another pair of eyes will often catch something you missed. Establish change procedures and processes Change requests must be communicated consistently so that the right people can review them and assess their impact. Many problems can be avoided simply with good communication. Some organizations schedule weekly change review meetings to understand and plan complex changes. But the most effective way to ensure that changes are reviewed and approved is by enforcing a change process workflow. Establish a test plan for all changes It may sound surprising, but many changes are tested for hours or days after implementation, while some are never tested at all. A test plan for every change is a critical part of the change process. Sometimes this isn't as easy as it sounds and involves coordinating end users, business partners, and professional testers. The work you put in here will build credibility in your teams' ability to get things right. Monitor the environment The firewall environment should be continuously monitored and abnormal behavior should automatically trigger alerts.  The firewall environment might include the operating system, the network interfaces, the firewall software, the firewall hardware, and the firewall rule base.  These should be analyzed and correlated and, if necessary, escalated for a closer look. Listen to your users A helpdesk should be in place so that users can easily report problems. The helpdesk should be manned with trained personnel and have clear processes for handling incidents. Have a plan for correlating multiple incidents to a single problem. Each team should have tools to assist root cause analysis before escalation to the next level. Maintain accessible, actionable audit information Each and every change must be documented properly and recorded in an audit trail. A comprehensive audit trail should include the target device, the exact time of the change, the configuration details, the people who were involved (requestor, approvers, implementor), and the change context such as the project or application. But a detailed audit trail is not enough on its own. The information must also be presented in an easy-to-read format so that you can easily access it when needed. Additionally, you'll want to have filtering and querying capabilities on top of the data to speed up searches and lookups. Prepare for rapid recovery Now comes the incident. Despite everything, something bad has happened and you need to respond. You will be judged by the time it took to recover, so you want to be well-prepared with tools, staff and processes to handle this. You want to keep stress down to a minimum. If you have set up the procedures above, you are already in pretty good shape. Either you caught the problem during the change process or, if it was missed, you can discover it early, before users and services are affected. Thanks to the audit trail, you know exactly what changes have been made lately, by whom, and why. Experts agree that most recovery time is spent figuring out what changed; so if you already know, recovery times are going to be much shorter. You run some quick queries to pinpoint likely suspects and you can roll-back the changes quickly. If you use Tufin solutions, there are a number of tools that can help you control changes, detect problems, and recover from errors: A complete audit trail with full accountability and integration with ticketing systems Comprehensive change reports and side-by-side diffs for rule bases, objects and textual configurations Real-time change notifications with filtering (by change type, device, affected networks) Central console for viewing all recent changes across all devices regardless of vendor and model A policy analysis tool for determining which firewalls and rules are blocking services across an environment Rule and object change history reports Business process automation to manage the change process (SecureChange Workflow) and integration with existing ticketing systems Let us know how you recover from configuration mistakes. Reuven http://www.tufin.com/blog/rss/blog/posts/2010/march/tufin-firewall-expert-tip-5-nasty-configuration-mistakes-how-to-avoid-them-and-how-to-recover/ http://www.tufin.com/blog/rss/blog/posts/2010/march/tufin-firewall-expert-tip-5-nasty-configuration-mistakes-how-to-avoid-them-and-how-to-recover/ Sun, 14 March 2010 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2010/march/record-sales-and-growth-in-2009,-market-validation-by-gartner/ Hi everyone, It's been a while since my last post… First off, today we announced record numbers and growth in 2009 : 45% revenue growth over 2008, over 4000% aggregate revenue growth in the past 5 years, moving from 280 to over 500 customers, and much more. It was especially challenging to achieve this in a year like 2009, which was not "optimal", to say the least. We maintained profitability and were again cash-flow positive (we've always been cash-flow positive, and it's a tradition we expect to continue). Those of you at Tufin, as well as our customers and partners, know that the real "secret sauce" is having great people - it's a pleasure and an honor to work with such a talented team, and I'm constantly inspired by everyone at the company. We are continuing our growth in 2010 with many new open positions, in sales, marketing, support and R&D - we're always looking for great people to join the Tufin family. Another interesting piece I heard today was a podcast by Vic Wheatman and Greg Young, VP of research at Gartner , who specializes in network security and firewalls (podcast available for Gartner customers only). The podcast topics were mostly Next Generation Firewalls, and Firewall Policy Management. Greg indicated that the two areas of innovation around the firewall space are the NG firewalls, and of course the area of Firewall Policy Management. Firewall policy optimization and workflow were mentioned as topics that  are key, and referred to as the future of firewalls. Greg is absolutely right in his assessment of the market - we've been talking about this for the past few years, and now it seems that the concept of vendor-neutral firewall policy management has finally taken hold. The market validation is there (500 enterprise customers can't be wrong), and the products have matured enough to be widely accepted. It's great to have validation not just from the customers, but also from the security experts and opinion leaders out there. http://www.tufin.com/blog/rss/blog/posts/2010/march/record-sales-and-growth-in-2009,-market-validation-by-gartner/ http://www.tufin.com/blog/rss/blog/posts/2010/march/record-sales-and-growth-in-2009,-market-validation-by-gartner/ Wed, 10 March 2010 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2010/february/security-moving-beyond-firewall-configuration-management/ Platen describes the ultimate network management suite with a comment from me: http://platen.wordpress.com/2010/02/10/security-moving-beyond-firewall-configuration-management/ http://www.tufin.com/blog/rss/blog/posts/2010/february/security-moving-beyond-firewall-configuration-management/ http://www.tufin.com/blog/rss/blog/posts/2010/february/security-moving-beyond-firewall-configuration-management/ Mon, 15 February 2010 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2010/february/tufin-firewall-expert-tip-4-vendor-and-model-specific-tips-for-optimizing-firewall-performance/ Do your firewalls need a tune-up? In our last column , we looked at general ways that firewall performance can be improved to overcome problems such as high CPU utilization, low throughput, and slow applications. This time, we are following up with a list of vendor and model-specific tips and best practices that can help you to optimize your firewall infrastructure. Thank you to everybody who responded to the last column and sent in their own tips! Check Point Use networks instead of address ranges in NAT. Avoid rules with Ident. Replace nested groups by flat groups. Be aware of configurations that SecureXL templates (fastpath) cannot handle, for example, security server, or syndefender. Note that SecureXL templates can be disabled from a certain rule onwards due to certain configurations such as client auth, time objects, etc. Be aware of configurations that SecureXL cannot handle, for example: FloodGate-1 (automatically disables SecureXL) Rules with user authentication Services with a port number range (disables connection-rate acceleration) Time object associated with the rule (disables connection-rate acceleration) Be aware of SmartDefense configurations that may impact performance: Network Security->Fingerprint scrambling->ISN spoofing Network Security->Fingerprint scrambling ->TTL Cisco all models Debug messages are known to affect performance. PIX 6.3 TCP Intercept is known to impact performance. If you are not using NAT and have no DNAT communications, disable the ILS fixup. Cisco IOS Firewall Performance may be affected if the value of 'ip inspect one−minute high' is far greater than the value in the 'show ip audit stat' command. Cisco ASA Verifying TCP checksums may impact firewall performance. Ideal performance is achieved when traffic enters and exits ports on the same adapter or ports on adapters serviced by the same I/O bridge (ASA 5580). Cisco FWSM Deep packet inspection may cause high CPU (all inspection engines except for SMTP are handled in software). Before release 3.1, non UDP or TCP or ICMP flows are handled on a packet by packet basis. With 3.1 and higher, the FWSM creates flows in NP1 and NP2. Be aware of features that are not offloaded to network processors, they will use the CPU. Built-in ACL optimization algorithm: FWSM Release 4.0 incorporates an algorithm capable of optimizing ACLs by coalescing contiguous subnets referred to in different access-control entries into a single statement and detecting overlaps in port ranges. Note that after the optimization process, the ACL is likely to be different from the original one. Juniper (ScreenOS) ALG (application layer gateway) is applied globally to all policies by default but may have a major impact on performance. Disabling it on specific policies can make a significant improvement. On high-end firewall platforms, NS-5000, ISG-1000 and ISG-2000, with ScreenOS 6.2 and above, Juniper switched the default rule search algorithm from "hardware" (ASIC) to "software" (CPU). The software search algorithm provides faster policy search time compared to older versions, when the number of "rules" for a pair zone is more than 500 rules, but it could cause high CPU during policy changes. ScreenOS 6.1: using wildcard address/wildcard policy causes a performance penalty. Fortinet Enable only the required management features you need. If you don't need SSH or SNMP, don't enable them. Enable only the required application inspections. Minimize use of alert systems. If you export syslog, you may not need SNMP or email alerts. Establish auto-updates (scheduled update) at a reasonable rate. Every 4 or 5 hours should be ok on most cases. Minimize use of Protection Profiles. If you don't need a Protection Profile on a firewall rule, don't put it there. Minimize use of Virtual Domains and avoid them completely on low-end models. Avoid Traffic Shaping if you need maximum performance. By definition, Traffic Shaping slows down traffic. As usual, I'd love to have your feedback, Reuven. http://www.tufin.com/blog/rss/blog/posts/2010/february/tufin-firewall-expert-tip-4-vendor-and-model-specific-tips-for-optimizing-firewall-performance/ http://www.tufin.com/blog/rss/blog/posts/2010/february/tufin-firewall-expert-tip-4-vendor-and-model-specific-tips-for-optimizing-firewall-performance/ Tue, 09 February 2010 00:00:00 http://www.tufin.com/blog/rss/blog/posts/2010/january/tufin-firewall-expert-tip-3-best-practices-for-optimizing-firewall-performance/ Is your firewall overloaded? Symptoms include high CPU, low throughput and slow applications.  Before upgrading your hardware, it is worth checking whether the firewall configuration can be optimized. Optimization techniques can be divided into two groups - general best practices, and vendor-specific, model-specific configurations. This column focuses on best practices. Next time, we will look at vendor-specific tips, so if you have any to share, we would like to hear from you. Optimizing firewalls for better performance and throughput: Remove bad traffic and clean up the network.  Notify server administrators about servers hitting the firewall directly with outbound denied DNS/NTP/SMTP/HTTP(S) requests as well as dropped/rejected internal devices. The administrators should then reconfigure the servers not to send this type of unauthorized outbound traffic, thereby taking load off the firewall. Filtering unwanted traffic can be spread among firewalls and routers to balance the performance and effectiveness of the security policy. Identify the top inbound dropped requests that are candidates to move upstream to the router as ACL filters. This can be time consuming, but it is a good method for moving blocks upstream to the router and saving firewall CPU and memory. If you have an internal choke router inside your firewall, also consider moving common outbound traffic blocks to your choke routers, freeing more processing on your firewall. Remove unused rules and objects from the rule bases. Reduce rule base complexity - rule overlapping should be minimized. Create a rule to handle broadcast traffic (bootp, NBT, etc.) with no logging. Place the heavily used rules near the top of the rule base. Note that some firewalls (such as Cisco Pix, ASA version 7.0 and above, FWSM 4.0 and certain Juniper Networks models) don't depend on rule order for performance since they use optimized algorithms to match packets. Avoid DNS objects requiring DNS lookup on all traffic. Your firewall interfaces should match your switch and/or router interfaces.  If your router is half duplex your firewall should be half duplex.  If your switch is 100 Mbit your firewall interface should be hard-set to match your switch; both should most likely be hard-set to 100 Mbit full duplex. Your switch and firewall should both report the same speed and duplex mode. If your switch is gigabit, your switch and firewall should both be set to auto-negotiate both speed and duplex.  If your gigabit interfaces do not match between your firewall and switch, you should try replacing the cables and patch panel ports. Gigabit interfaces that are not linking at 1000 Mbit full duplex are almost always a sign of other issues. Separate firewalls from VPNs to offload VPN traffic and processing. Offload UTM features from the firewall: AV, AntiSpam, IPS, URL scanning. Upgrade to the latest software version. As a rule of thumb, newer versions contain performance enhancements but also add new capabilities, so a performance gain is not guaranteed. If you use Tufin SecureTrack, you can automate a number of these tasks. Here are a few ways that SecureTrack can help: Identify unused rules and objects with the Rule and Object Usage Report, and consider removing them. The longer the reporting period, the more reliable the rule usage status will be. Remember that certain rules, like the ones allowing disaster recovery services, are only used rarely. You can also identify and cleanup unused group members. Analyze rule shadowing with Policy Analysis. Run Policy Analysis with "Any;Any;Any;Any" to identify completely shadowed rules. These rules are redundant and should be deleted. You can re-validate the redundancy with an unused rules report. Identify the most-used rules with the Rule and Object Usage Report and move them up in the rule base hierarchy. To find the top-most location for placing a rule without affecting connectivity, run an "Any;Any;Any;Any" policy analysis query, then, for each most-used rule: If it is not shadowed, move it to any higher location. If it is shadowed, find the lowest-ranked shadowing rule with a contradictory action and place the most-used rule below that one. Other things to keep in mind when re-ordering rules: You'll probably want to preserve the rule base structure, for example, rule grouping by service or application, source or destination, projects etc. Be careful with policies containing rules with special actions such as authentication or encryption - shadowing becomes more tricky in this case. You may also use the Best Practices Rule Order Optimization test to quickly identify candidates for relocation. Use the Automatic Policy Generator (APG) to identify and remove unwanted traffic from the firewall. Read more about APG here . Use the "Software Version Compliance Report" to control your firewall software versions. Last but not least, remember that optimization can have a price, too - beyond the time you've invested. If you are not careful, you can wind up with a rule base which is too hard to maintain.  If you have the budget, there are times when upgrading the hardware is the easiest alternative. In our next column, we'll focus on ways to optimize specific models of firewalls from the different vendors. If you have any tips that you would like to share, please contact me at rh@tufin.com . http://www.tufin.com/blog/rss/blog/posts/2010/january/tufin-firewall-expert-tip-3-best-practices-for-optimizing-firewall-performance/ http://www.tufin.com/blog/rss/blog/posts/2010/january/tufin-firewall-expert-tip-3-best-practices-for-optimizing-firewall-performance/ Mon, 11 January 2010 00:00:00