Beyond Boundaries: Leveraging No-Code Solutions for Industry Innovation
Alphabet Soup: A(utomation), BC (Business Continuity) and DR (Disaster Recovery
1. Alphabet Soup – A(utomation), BC(Business
Continuity) and DR (Disaster Recovery)
Christopher Rogers
Senior Technical Advisor, Intelligent Infrastructure
Internetwork Engineering
2. Agenda
• BC or DR? Defined….
• Business Continuity (BC)
• Disaster Recovery (DR)
• What about “Cloud”?
• Other Thoughts
• Automation
• Conclusion
3. What does it take to make a great soup?
A good base – maybe start with the trinity
(onions, celery, and bell peppers) sautéed
A good broth (probably chicken)
Layer in other flavors and ingredients
4. • How many have a DR Plan?
• How many have a BC Strategy?
• How many thought they had a BC Strategy because they had a DR Plan?
• May not be you, but what about others in your organization?
• How many are performing some type of automation in IT?
Quick Status Check
6. BC or DR? Defined…
The processes, procedures,
and solutions needed to make
sure an organization can
continue to function
The plan an organization has in
place to recover data or
technology losses
Business Continuity Disaster Recovery
Business Continuity
Disaster
Recovery
Focused on planning for the
restoration and recovery of any
technology functionality or data
that was lost
Focused on risk analysis and
planning to ensure the
business can continue to
operate
8. Business Continuity Questions
• What is the organization’s primary function?
• What secondary functions support the primary
function?
• How does the organization perform its function?
• What processes and procedures that govern this
function?
• Are these functions offered virtually? Online,
telephone?
• Are there compliance/legal requirements that govern
how the functions are performed?
• Where do employees perform their job functions?
• Do they come to a brick and mortar?
• What do they use to perform their job functions?
9. Business Continuity Questions context
• What is the organization’s primary function?
• What is the impact/result of this function not being performed? Can the loss be quantified?
• Who (what) is affected by the loss of the primary function? How long can the constituents
continue without this function?
• What secondary functions support the primary function?
• Are these secondary functions essential to the operation of the primary function? What is the
operational impact of operating without a given secondary function?
• How does the organization perform this function
• What processes and procedures that govern this function? Essential processes?
• Can and are these functions offered virtually? Online, telephone? Require employee
interaction?
• Are there compliance/legal requirements that govern how the functions are performed?
• What requirements govern these functions? If necessary, can special operating procedures be
implemented?
• Where do employees perform their job functions?
• Do they HAVE come to a brick and mortar? If so has a location been identified?
• What do they use to perform their job functions? How do they work?
• No brick and mortar? Can they work virtually, What do they need to work virtually, Are
process changes needed to work virtually?
• May have to make hard decisions
• Not all business functions are truly necessary to support primary function
• Understand how to re-incorporate secondary business functions and impact
• Incident Response – Is your incident response incorporated?
Key Ingredient:
1) Know the top (up to 5)
critical function(s) of the
organization.
2) Think like a business,
what is the bare minimum
need to stay in operation
during the event and after
the event.
3) Incident Response
10. Why BC Strategy
– Scenarios
• Pandemic
• Regional Disaster
• Primary (Only) Site
• Many others …
11. Disaster Recovery Questions
• How is the organization’s primary function impacted by loss of
technology?
• What technology services support the organization’s primary
function?
• Is technology service dependency understood?
• What technology services support the organization’s secondary
functions?
• What compliance/legal requirements govern technology services?
• Are Service Level Agreements between organizational groups and the
technology group in place?
• What is the expected RPO (Recovery Point Objective)?
• What is the expected RTO (Recovery Time Objective)?
12. Disaster Recovery Questions context
• How is the organization’s primary function impacted by loss of technology?
• Can the primary function be performed without technology? If so, for how long? What is the perception
if technology services are lost?
• What technology services support the organization’s primary function?
• Is technology service dependency understood and documented? Have all technology services that
support the function been identified? Rank services, Know the order of service resumption, Understand
prerequisites for services
• What technology services support the organization’s secondary functions? Ask same questions
• What compliance/legal requirements govern technology services? What impact do compliance/legal
requirements have? How do requirements impact ability to perform disaster recovery?
• Are there DOCUMENTED Service Level Agreements (SLAs) between organizational groups and the
technology group in place? Does the organization understand the impact of fulfilling the SLAs?
(BC quantifies loss of ability to perform primary function)
• What is the expected RPO (Recovery Point Objective)? How much data loss is acceptable?
• What is the expected RTO (Recovery Time Objective)? How quickly do the technology services need to
be restored?
• Have to make hard decisions
• Not all technology services will be required for primary function
• Understand how to re-incorporate secondary services and impact
• In House - Start Small
• One Application that supports primary function or major secondary function
• Preferably one that has well documented guidelines and recommendations for DR
• Seek Assistance – Still Start Small
• Onboarding – As Applications are added or replaced – Assess and incorporate into DR
• Incident Response – Align your cybersecurity IR process with DR
Key Ingredient(s):
1) Know technological
dependencies for the top
(up to 5) function(s)
2) Availability path for the
technological
dependencies
3) Incident Response
13. Why DR Plan – Scenarios
• Localized (DC Center) Issues
• Ransomware – Malicious behavior
• Human Error
• Many others …
14. What About the “Cloud”?
• Primary Technology Platform
• IaaS, PaaS, SaaS, DaaS, BaaS, DRaaS
• Business Continuity
• Provide worker access to IT Resources (DaaS)
• DR
• IaaS, PaaS, SaaS, DRaaS, BaaS
• Things to think about
• Backups
• Provide redundancy – not backups
• Disaster Recovery
• Provide redundancy – but not normally beyond site
unless chosen
• Data Movement
• Free to bring in – Pay to leave
• Alternative Cloud https://docs.microsoft.com/en-
us/azure/architecture/resiliency/disas
ter-recovery-azure-applications
15. Things to think about
• Practice, Practice, Practice
• More Practice
• People
• Where are they?
• Are they affected by the situation?
• To what extent are they affected?
• What is the personal effect on them?
• Will they be able to fulfill their duties?
• Third Party
• Logistical
• Physical Access
• Card Access?
• Disaster causes card process to fail?
• Impassable?
• Documentation – secondary copy?
• BC/DR Equipment
• Understand where you are in CIP (Critical Infrastructure Protection)
• https://www.dhs.gov/what-critical-infrastructure
16. Automation
• Why Automation?
• Get things done faster!?!
• Steps to Automation –
• Looks for repetitive tasks
• Understand what we want to automate
• Document the process
• Standardize the process
• Utilize best practice
• Results of Automation
• Faster deployment
• Documented deployment
• Consistent deployment – less human error
• Better maintenance processes – help stay up to date
17. Automation – Reservations
• We’re too small organization – Don’t need Automation
• Moving to the Cloud
• Don’t have a mature IT process or governance
• Automate myself out of a job
• Automate yourself into a disaster!?
• Build out in layers
• Treat like Dev Process – Test, Test, Test (not in Production )
• Where to start
• Semi-automate processes
• Change Management
• Request and approval
• Update BC/DR
• MAC (Moves, Adds, Changes)
• Information gathering
• Existing setups and configurations
• Topology
18. Automation – Impact
• BC/DR Impact
• Documented process for service restoration
• Known good configuration state
• Systematic restoration
• Faster restoration time
• Organizational Results
• Business continuity strategy and disaster recovery plan can be better maintained
• Less downtime of mission critical applications when a disaster or unexpected event
occurs
• Reduced risk of downtime due to human error
• Confidence that the recovery process is solid
• Reduced risk of recovery process failure due to inaccurate information or human
error
Key Ingredient:
Automation can make
your BC/DR process
better.
19. Conclusion
• What are the top 5 critical functions of the
organization. If the organization were a business,
what is the bare minimum it would take to stay in
business during the event and after the event.
• What technological dependencies do those top 5
functions require?
• What is the availability path for the technological
dependencies, should an event occur? Meaning, if an
event affects those resources, what is the
contingency.
• Incident Response
• Know how it integrates
• IR may require BC or DR to be put in motion
• Automation – Its your friend
20. Thank you!
Questions?
Christopher Rogers
SeniorTechnical Advisor – Intelligent Infrastructure
SNR (704) 944-0072 | crogers@ineteng.com
Raleigh Security Users Group (Quarterly) – next mtg 6/7
Charlotte Security Users Group (Bi-monthly) – next mtg 6/22
www.ineteng.com/events