Reorganizing Federal IT to Address Today's Threats
•Download as PPT, PDF•
0 likes•509 views
New reports show U.S. government servers are faced with 1.8 billion cyber attacks every month. View this technical presentation on ‘Reorganizing Federal IT to Address Today’s Threats’ by Richard Stiennon, analyst with IT Harvest and author of Surviving Cyber War, and Paul Zimski, VP of Solution Strategy with Lumension, as they examine: *Today’s threats targeting government IT systems *How federal IT departments can be reorganized to improve security and operations *What key endpoint security capabilities should be implemented Get expert insight and recommendations on improving your approach to securing IT systems from today’s sophisticated threats.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Reorganizing Federal IT to Address Today's Threats
Similar to Reorganizing Federal IT to Address Today's Threats (20)
More from Lumension
More from Lumension (20)
Recently uploaded
Recently uploaded (20)
Reorganizing Federal IT to Address Today's Threats
- 1. Reorganizing Federal IT to Address Today’s Threats
- 2. Today’s Speakers Paul Zimski VP of Solution Strategy Lumension Richard Stiennon Analyst and Author IT Harvest
- 3. Today’s Agenda Today’s Threats Targeting Government Systems How to Reorganize Federal IT Examining Key Security Strategies Q&A
- 4. New Threats to Federal IT Systems
- 7. How to Reorganize Federal IT
- 11. Introducing the cyber defense team Cyber Commander Analysts Operations Red Team
- 18. The attackers have changed their tools, targets, and goals. The defenders must change too.
- 20. Examining Key Security Approaches
- 22. Strategy 1: Defense-in-Depth Traditional Endpoint Security Defense-N-Depth Blacklisting As The Core Zero Day 3 rd Party Application Risk Malware As a Service Volume of Malware Patch & Configuration Mgmt.
- 23. Strategy 2: Trust-Based Security
- 29. Q&A
Editor's Notes
- © Copyright 2008 - Lumension Security
- Defense in Depth Strategy Address the core IT Risk with Patch & Configuration Management Stop unwanted / untrusted change with Application Control Protect against insider risk Device Control Deploy a broad defensive perimeter with AntiVirus Reduce endpoint complexity with an Endpoint Management and Security Suite
- On top of defense-in-depth, time to shift from threat-centric approach to one based on trust….
- Application control or whitelisting provides a new layer in the foundation for endpoint protection. Whitelisting is about identifying the known good and by default not letting anything other than what’s on the whitelist from executing. Simply put, any executable – whether a business application, a video driver, or a web browser plug-in – not specified on the whitelist cannot load and run. It’s the most effective security layer as its prevents execution in the kernel.
- Trust Engine Challenge . Organizations need an automated method by which to determine whether or not to allow changes to the code running on their network assets, particularly the endpoints, in order to make the promise of application whitelisting operationally feasible. Without this, changes to the whitelist had to be made manually and oftentimes without any basis. The challenge is to implement a process by which changes can be automatically vetted and installed on network assets. Feature . LEMSS:AC allows any number of trust policies to be created and implemented which will automate the process of assessing the security and desirability of changes to programs running on network assets; these trust mechanisms allow for the automated or user-driven changes to the “known good” whitelist required in dynamic environments such as desktops and laptops without completely surrendering control over these changes. These trust mechanisms include: Trusted Publisher , Trusted Updater , Trusted Path , and Local Authorization . Benefit . This permits the organization to provide the higher level of security against malware and other undesirable programs available from a whitelisting / “default deny” approach without the additional administrative burden sometimes associated with it. Some specific examples of how the Trust Engine might help operationalize whitelisting in a real IT network with dynamic environments such as desktops or laptops include: Trusted Publisher (i.e., from a known good vendor with a signed certificate) – the organization may have whitelisted a specific Microsoft Operating System (OS) and applications (e.g., Word, Excel and Powerpoint) but finds that some users may want to add certain OS capabilities (such as additional drivers) or applications (such as Visio) from Microsoft; by implementing a policy which permits changes to the whitelist when those changes are accompanied by a valid, signed certificate from Microsoft, these changes could be made “on the fly” by the end user without additional work for the system administrators. Trusted Updater (i.e., from a known good process which updates existing software) – the organization may be using an automated patching solution (such as Lumension Patch and Remediation) or have certain continuously updated programs (such as WebEx) on their whitelist. Here again, by implementing a policy which permits changes to the whitelist when those changes are made by these specific programs, these changes could be made automatically without adding to the administrative burden. Trusted Path (i.e., from a known good location, generally inside the network) – it is not uncommon for IT administrators to create a library of known good applications, which is used when installing or updating an endpoint; organizations might want to restrict all endpoint changes to only those which come from this “source repository.” By creating / using a trusted path policy (and carefully controlling access to this “source repository”), the whitelist can be updated as changes are made in the library of known good applications. Local Authorization (i.e., allow specific users to self-authorize applications) – in some cases, an organization might allow specific users to augment the whitelist of known good applications under their own say-so, be they administrators or even end users; for instance, perhaps a “well known” salesman is on a customer call and needs to update her machine to allow her presentation to work on the customer’s equipment. This trust mechanism provides a way to permit these ad hoc changes while providing the traceability and control needed to ensure that, should they prove unwise, they can be reversed.