Your security guy knows nothing
This talk focused on the changes to security / security mindsets required by the move to cloud hosted or hybrid architectures. The title was mainly as an attention grabber, but the talk overall was interesting and made some good points around what is changing, but also the many concerns that are still basically the same.
– Fat guy with keys; IT focused; “You can’t do that”; Does not understand software development.
– Processes and gates; Tools and people; Good for Building; Not as good for acquiring / mashing
Traditional security wants certainty –
– Where is the data? – in transit, at rest, and in use.
– Who is the user?
– Where are our threats?
What happens to data on hard drives of commodity nodes when the node crashes or the container is shipped back to the manufacturer from the CSP? (data at rest etc.). The new world is more about flexible controls and polices than some of the traditional, absolute certainties.
Security guys want to manage and understand change;
– Change control process
– Risk Management
– Alerts when things change that affect the risk profile
Whole lifecycle – security considered from requirements onwards, not tacked onto end of process.. This for me is a key point for all security functions and all businesses. If you want security to be ingrained in the business, effective, and seen as an enabler of doing things right rather than a blocker at the end, it must always be incorporated into the whole lifecycle.
Doing it right – Business –Development – Security – Working together..
– Render the Implicit Explicit
– Include security in design
- Even in acquisition
- Even in mash ups
– Include security in requirements / use cases
– Identify technical risks
– Map technical risks to business risks (quantify in money where possible)
– Trace test cases
- Not just to features
- But also to risks (non functional requirements!)
– Provide fodder (think differently, black hat / hacker thinking)
– Provide alternative reasoning
– Provide black hat mentality
– Learn to say “yes”
– Provide solutions, not limitations!
Goal – Risk management
Identify how the business is affected?
What can techies bring to the table?
– Estimates of technical impact
– Plausible scenarios
– Black Hat thinking
Compliance – does not equal – Security!
– Ticking boxes – does not equal – Security!
So the key take away points from this are that regardless of the changes to what is being deployed –
– Work together
– Involve security early
– Security must get better at saying ‘yes, here’s how to do it securely’ rather than ‘no’
No PDF of this presentation is currently available.
Moving applications to the cloud
This was another Gartner presentation that covered some thoughts and considerations when looking at moving existing applications / services to the cloud.
– What are our options?
– Can we port as is, or do we have to tune for the cloud (how much work involved?)
– Which applications / functions do we move to the cloud?
– Which vendor?
– IaaS, PaaS, SaaS…?
– How – rehost – refactor – revise – rebuild – replace – which one?
- Rehost or replace most common, quickest and likely cheapest / easiest
You need to have a structured approach to cloud migrations, likely incorporating the following 3 stages;
– Identify candidate apps and data
- Application and data-portfolio management
- Apps and data rationalisation
- Legacy modernisation
– Assess suitability
- Based on cloud strategy goals
- Define an assessment framework
- Risk, business case, constraints, principles
– Select migration option
- rehost – refactor – revise – rebuild – replace
This should all be in the context of;
– What is the organisations cloud adoption strategy
– What is the application worth? What does it cost?
– Do we need to modernise the application? How much are we willing to spend?
In order to make decisions around what to move to the cloud and how to move it you should define both your migration goals and priorities which should include areas such as;
– Gain Agility
- Rapid time to market
- Deliver new capabilities
- Support new channels (e.g. Mobile)
– Manage costs
- Preserve capital
- Avoid operational expenses
- Leverage existing investments
– Manage resources
- Free up data centre space
- Support scalability
- Gain operational efficiencies
Some examples of what we mean by rehost / refactor / revise / rebuild / replace;
Rehost – Migrating application – rehost on IaaS
Refactor – onto PaaS – make changes to work with the PaaS platform and leverage PaaS platform features
Revise – onto IaaS or PaaS – at least make more cloud aware for IaaS, make more cloud and platform aware for PaaS
Rebuild – Rebuild on PaaS – start from scratch to create new, optimised application.
Note – some of these (rebuild definitely, refactor sometimes) will require data to be migrated to new format.
Replace – with SaaS – easy in terms of code, data migration, business process and applications will change (large resistance from users is possible).
The presentation ended with the following recommendations;
– Define a cloud migration strategy
– Establish goals and priorities
– Identify candidates based on portfolio management
– Develop assessment framework
– Select migration options using a structured decision approach
– Be cognizant of technical debt (time to market more important than quality / elegant code!)
- Do organisations ever plan to pay back ‘technical debt’? Where Technical debt refers to corner cutting / substandard development that is initially accepted to meet cost / time constraints.
A pdf of this presentation can be downloaded from here;
Overall another good presentation with very sensible recommendations covering areas to consider when planning to migrate applications and services to the cloud.