docDesigning Secure Event-Driven Architectures - Mil-OSS
download 
Report Transcription
Designing Secure Event-Driven Architectures - Mil-OSS
Designing Secure Event-Driven Architectures Richard Clayton Chief Engineer Road Map • About Us • Objectives • Ten Considerations for Securing Event-Driven Architectures • • • • • • • • • • Preliminary Research and Planning Choose the Right Security Frameworks Employ Redundant Security Measures Minimize Privileges in the Architecture Go Beyond Authentication and Authorization Use Multidimensional Security Scope Authorization Secure Mixed Datasets Secure Services Secure Messages and Events • Conclusion About Us Berico Technologies Passionate, high-end software engineering, consulting, and analytic services provider to the federal government. Berico’s mission is to leverage tremendous operational experience and the best industry talent to identify and solve our clients’ hardest problems. •Founded in 2006 •Presence in DC, MD, VA, FL, AZ and IZ, AF •Best Places to Work Greater Washington: 2010,2011 •Finalist for Hottest Emerging Government Contractor •Winner of SMARTCXO Executive Management Team •AFCEA Meritorious Award for Engineering Richard Clayton Chief Engineer Previously an Engineer, Tech Lead, and Project Manager (2009-2011) Tech Focus -Service Oriented Architectures -Event-Driven Architectures -Distributed Computing -Domain Modeling Education BS in Computer Science (Park University) Cloudera Developer Certified Eons Ago… US Marine Corps (2000-2009) SSgt / Weather Forecaster -Certified Weather Forecaster -Certified Weather Observer Objectives Help you achieve a higher-level of security (and confidence) within your architecture by emphasizing the lessons we have learned during our accreditation experiences. • Emphasize security as a first class citizen within your domain model. • Describe the breadth of security considerations when designing a secure architecture. • (Briefly) discuss the implementation of security across distributed architectures (SOA and EDA). Ten Considerations for Securing Event-Driven Architectures Preliminary Research and Planning • Understand the scope of security requirements before designing Read appropriate documentation • Determine the appropriate security goals of the system. This should include your accreditation goals • Consider implementing a higher security level than required. Unplanned elevation of security requirements is common • Get your System Administrators/Engineers involved! • Beautiful architecture is a marriage of hardware and software • Hardware may solve security/scalability limitations of software • Security should be a first-class citizen in your domain model • Preserve Pedigree and Provenance on all pieces of data. • Consider making ACL’s a part of your object model. Choose the Right Security Frameworks • Don’t invent your own security framework!!!! Unless that’s what you do for a living… • Choose a proven, enterprise-grade technologies • For internal networks, Kerberos and LDAP is an excellent option. • Larger networks with greater latency are better suited by publickey encryption-based authentication technologies. • Reuse existing infrastructure (if possible) and integrate legacy systems. If you have an AD instance within the organization, use it! • Consider using Single-Sign On (SSO) Managing 800 passwords is annoying and encourages users have bad habits Employ Redundant Security Measures • Protect data in transit Even in protected areas of the network • Securely store data “at rest” Encryption, redundant storage, File System and DB ACL’s • Layer your network Use firewalls between zones • Restrict access in each “tier” of the application Within the UI, at the Service Layer, at Data Sources • Hide or obfuscate the “guts” of your application from the user Are “power users” allowed to define there own SQL Where clauses? • Utilize system-enforced usage policies Group Policy is a perfect example Minimize Privileges in the Architecture Next to “malware”, malicious insiders are the greatest security threat to a computer network. (Paraphrased) http://www.networksecurityedge.com/content/top-10-information-security-threats-2010 •Reduce the rights of O&M personnel on the network • Does everyone need to be a “Domain Admin”? • If they do, do they need to be one all the time? •Segregate the roles and rights of personnel on the network Think “Checks and Balances” •Do not reuse service accounts Consider having one per service •Minimize the privileges of services accounts Few services need administrative privileges Go Beyond Authentication and Authorization • Auditing • Expose application logs • Use a consistent format (easier to extract information) • Have an export strategy • Use an Audit Reduction tool • Have a multi-tiered archiving strategy • Availability • Employ redundancy in architecture • Load Balancers • Replication of File System and Storage • Hardware/Network redundancy • Write working code! • Make Unit Testing and Continuous Integration apart of your design strategy (TDD and BDD anyone?) • Choose horizontally-scalable solutions Go Beyond Authentication and Authorization • Policy • Application Policy • Trap requests through a gateway • Apply a rules engine against requests • Operating System Policy • Specify non-computer-enforceable policies in an SOP Use Multidimensional Security Just like Relational Databases and Object-Oriented Programming, there is an “impedance mismatch” between DOD/IC needs and operating system security models. •DOD/IC security needs tend to be multidimensional (3D & 4D if you will), and OS security models are two-dimensional. • Operating System roles/groups describe what a user can do or access, but not whether a user “should” given the current state of the system. • Real-world policy breaks this model (e.g.: no user should be able to access dataset “A” after 6pm unless they have their supervisor’s permission) •Rules Engines, Complex Event Processors, and Workflow can give you the flexibility to enforce multidimensional security models. Scope Authorization • Treat every piece of information consistently Regardless of how sensitive it is • Determine the granularity of security within a system. • This may be imposed based on accreditation level • Permissions at the corpus-level. • You should already be carrying information about the dataset on every object within your domain model. • Dynamically create and enforce security roles/groups for each dataset. • Atomic permissions per secure item. • Every piece of information has it’s own ACL. • Hint: This is actually easier than corpus-level security! • Users are their own authorization scope. Secure Mixed Datasets Cross-corpus/classification analytics throw a wrench into most security implementations. •Runtime analytics Produce cross-authorization scope in memory, per user •Preprocessed analytics • Create new authorization scopes based on the combined “classification” of mixed datasets. • Consider automatically assigning users to these new scopes as they are created. • Hint: Once again, this is easier to do with PL-4 (overall classification of cross-corpora datasets is the intersect of ACL’s from each dataset) Secure Services • Employ Service-to-Service authentication and authorization! • Proxy “unprotected” services by offloading authenticated requests into protected “enclaves” Apache HTTPD Proxy with Kerberos or Certificate Auth • Access data as the user whenever possible Kerberos delegation • Use function-specific connection pools with different service accounts for each One service account for reads, one for writes, one for management • Use contextual security within applications Make assertions about user rights, and don’t be afraid to throw exceptions! Secure Messages and Events • Employ Service-to-Bus, Bus-to-Bus authentication and authorization! • Make “authorization scopes” a part of the Message/Event model. • Who is allowed to consume an event? • Beware of event hierarchies • Events tend to have multidimensional security • Who is allowed to fire an event? • Create “mini-buses” (conceptually channels or currents in an event stream) • Don’t propagate events unnecessarily across buses of higher scope • Performance burden and security risk • Consider using encrypted envelopes. • Use Event Stream Processors and Complex Event Processors to monitor service behavior. Record abnormal activity. Conclusion Recap • About Us • Objectives • Ten Considerations for Securing Event-Driven Architectures • • • • • • • • • • Preliminary Research and Planning Choose the Right Security Frameworks Employ Redundant Security Measures Minimize Privileges in the Architecture Go Beyond Authentication and Authorization Use Multidimensional Security Scope Authorization Secure Mixed Datasets Secure Services Secure Messages and Events Contact Us. Questions? Berico Technologies, LLC 1501 Lee Hwy Suite 303 Arlington, VA 22209 (o) 703.224.8300 www.bericotechnologies.com Guy Filipelli, CEO [email protected] Richard Clayton, Chief Engineer [email protected] www.gettingcirrius.com We want you! [email protected]
