J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

February, 2010

  • J.D. Meier's Blog

    Agile Security Engineering

    • 1 Comments

    “It is not necessary to change. Survival is not mandatory.”—Edwards Deming

    I gave a talk for the developer security MVPs at the Microsoft 2010 MVP Summit last week.  While I focused primarily on Azure Security, I did briefly cover Agile Security Engineering.  Here is the figure I used to help show how we do Agile Security Engineering in patterns & practices:

    Agile Security Engineering

    What’s important about the figure is that it shows an example of how you can overlay security-specific techniques on an existing life cycle.  In this case, we simply overlay some security activities on top of an Agile software cycle.

    Rather than make security a big up front design or doing it all at the end or other security approaches that don’t work, we’re baking security into the life cycle.  The key here is integrating security into your iterations.

    Here is a summary of the key security activities and how they play in an agile development cycle:

    • Security Objectives – This is about getting clarity on your goals, objectives, and constraints so that you effectively prioritize and invest accordingly.
    • Security Spikes – In Agile, a spike is simply a quick experiment in code for the developer to explore potential solutions.  A security spike is focused exploring potential security solutions with the goal of reducing technical risk.  During exploration, you can spike on some of the cross-cutting security concerns for your solution.
    • Security Stories – In Agile, a story is a brief description of the steps a user takes to perform a goal.  A security story is simply a security-focused scenario.  This might be an existing “user” story, but you apply a security lens, or it might be a new “system” story that focuses on a security goal, requirement, or constraint.  Identify security stories during exploration and during your iterations.
    • Security Guidelines – To help guide the security practices throughout the project, you can create a distilled set of relevant security guidelines for the developers.  You can fine tune them and make them more relevant for your particular security stories.
    • Threat Modeling – Use threat modeling to shape your software design.  A threat model is a depiction of potential threats and attacks against your solution, along with vulnerabilities.  Think of a threat as a potential negative effect and a vulnerability as a weakness that exposes your solution to the threat or attack.  You can threat model at the story level during iterations, and you can threat model at the macro level during exploration.
    • Security Design Inspections – Similar to a general architecture and design review, this is a focus on the security design.  Security questions and criteria guide the inspection.  The design inspection is focused on higher-level, cross-cutting, and macro-level concerns.
    • Security Code Inspections – Similar to a general code review, this is a focus on inspecting the code for security issues.  Security questions and criteria guide your inspection.
    • Security Deployment Inspections – Similar to a general deployment review, this is a focus on inspecting for security issues of your deployed solution.  Physical deployment is where the rubber meets the road and this is where runtime behaviors might expose security issues that you didn’t catch earlier in your design and code inspections.

    The sum of these activities is more than the parts and using a collection of proven, light-weight activities that you can weave into your life cycle helps you stack the deck in your favor.  This is in direct contrast to relying on one big silver bullet.

    Note that we originally used “reviews” which are more exploratory, but we later optimized around “inspections.”  The distinction is that inspections use criteria (e.g. a 12 point inspection.)  We share the criteria using security checklists for design, coding, and deployment inspections.

    There are two keys to chunking up security so that you can effectively focus on it during iterations:

    1. Security stories
    2. Security frame

    Stories are a great way of chunking up value.  Each story represents a user performing a useful goal.  As such, you can also chunk up your security work, by focusing on the security concerns of a story.

    A security frame is a lens for security.  It’s simply a set of categories or “hot spots” (e.g. auditing and logging, authentication, authorization, configuration management, cryptography, exception management, sensitive data, session management.)   Each category is a container for principles, patterns, and anti-patterns.  By grouping your security practices into these buckets, you can more effectively consolidate and leverage your security know-how during each iteration.  For example, one iteration might have stories that involve authentication and authorization, while another iteration might have stories that involve input and data validation.

    Together, stories and security frames help you chunk up security and bake it into the life cycle, while learning and responding along the way.

    For more information on security engineering, see patterns & practices Security Engineering Explained.

  • J.D. Meier's Blog

    VMs for Web and Worker Roles in Windows Azure

    • 9 Comments

    This is my current mental model for Virtual Machines (VMs) for Web and Worker Roles in Windows Azure:

    VMs for Web and Worker Roles in Windows Azure v2

    On Windows Azure, you run your application in Web and Worker Roles.  Each instance of a Web or Worker Role runs in a VM.  You define how many instances of each Web or Worker role you want to run.  Windows Azure then spins up a VM for each instance.  You can choose from 4 flavors of VMs: one core, two core, four core, and eight core.

    Here is a summary of the key components:

    • Web Role - includes Internet Information Services (IIS) and can accept HTTP and HTTPS Requests.  A Web Role talks to a Worker Role indirectly through a queue, or you can talk directly using WCF.
    • Worker Role – is not configured with IIS and is primarily for background processing, such as queuing, monitoring, or ticket-system scenarios.
    • Windows Azure Agent – each VM has an agent that lets your application talk to the Windows Azure Fabric using an API.

    The load balancer spreads the incoming HTTP or HTTPS requests across your Web Role instances.

    For a higher-level view, see my related post, Windows Azure Platform at a Glance.

  • J.D. Meier's Blog

    Windows Azure Platform at a Glance

    • 3 Comments

    This is my first attempt at parsing and summarizing the Windows Azure Platform, so I expect it to evolve as I iterate on it.

    Windows Azure Platform at a Glance

    The Windows Azure platform is a set of cloud computing services for creating and consuming cloud applications and services.  The key components of the Windows Azure Platform are:

    • Windows Azure – provides virtualized compute, storage, and management for your cloud-based applications.  It’s effectively a “cloud OS.”
    • SQL Azure – provides cloud-based relational database services.
    • App Fabric – provides application infrastructure services for federated authorization and for distributed application challenges (service composition and connectivity challenges.)

    You can use the Windows Azure Platform from your applications running in the cloud and from on-premises applications.  For example, you might access data in the cloud from an on-premises app, or you might access local user accounts from an app in the cloud.

    Windows Azure
    Windows Azure provides compute, storage, and management through Microsoft data centers.   The key components are:

    • Compute Service - process requests.  Compute services are Virtual Machine (VM) instances that come in two types:  Web Roles and Worker Roles.  Web Roles include Internet Information Services (IIS) and can accept HTTP and HTTPS Requests.  Worker Roles aren’t configured with IIS and are primarily for background processing, such as queuing, monitoring, or ticket-system scenarios.
    • Storage Service – stores data.  It provides blobs, tables, and queues.  Blobs and tables are for storing and retrieving data, but queues are primarily for Web Role instances to talk to Worker Role instances in an asynchronous way.
    • Fabric – provides physical machines for compute and storage.  The servers for Windows Azure live within a Microsoft data center.  These servers are organized into a Fabric.   This Fabric of machines provides the compute and storage capabilities.  These physical machines host the VM instances that provide the compute services.  The machines are controlled by a Fabric Controller.   The Fabric Controller talks to a Fabric Agent on each machine.  The Fabric Controller determines which physical machines to spin up Web and Worker Role VM instances and it monitors the health of the VMs and the physical machines.

    For more on Windows Azure, see Windows Azure SDK (MSDN.)

    SQL Azure
    SQL Azure provides cloud-based services for relational databases, reporting and analytics, and data synchronization.  The main component is a SQL Azure Database:

    • SQL Azure Database - provides a highly available, scalable, multi-tenant database service hosted by Microsoft in the cloud.  It’s a cloud-based relational database service built on SQL Server technologies.  You can access a SQL Azure Database through a Tabular Data Stream (TDS) protocol, which means you can use any existing SQL Server client library, such as ADO.NET, ODBC, or PHP.

    For more information on SQL Azure, see SQL Azure (MSDN.)

    App Fabric
    Windows Azure platform AppFabric (formerly called “.NET Services”) provides common application infrastructure services for distributed applications.  The key components are:

    • Access Control – provides authentication and authorization services through rules and claims.  It’s a standards-based service that supports multiple credentials and relying parties.  It enables federated identity and supports Active Directory, as well as other identity infrastructures.
    • Service Bus - provides secure connectivity options for service endpoints that would otherwise be difficult or impossible to reach.  It supports various communication patterns such as relayed, buffered, bidirectional, publish-subscribe, multicast, streaming and direct-connect.  Service Bus provides infrastructure for large-scale event distribution, naming, and service publishing.  It helps address the challenges of firewalls, NATs, dynamic IP, and disparate identity systems.  Service Bus can provide a service with a stable Uniform Resource Identifier (URI) that you can be accessed by any authorized client application.  Service Bus supports REST and HTTP Access from non-.NET platforms and it supports standard protocols and extends similar standard bindings for Windows Communication Foundation (WCF.)

    For more on App Fabric, see App Fabric Service Bus (MSDN) and App Fabric Access Control (MSDN.)

    For more information on the Windows Azure Platform, here are some of the main Azure starting points:

  • J.D. Meier's Blog

    Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS)

    • 1 Comments

    In cloud computing, you might hear the terms SaaS, PaaS and IaaS.  These are simply different logical layers in the stack.  You can visualize it like this:

    SaaS PaaS and IaaS

    As you move up the stack, you increase abstraction.  As you move down the stack, you increase control.  Here is a brief summary of each term:

    • Infrastructure as a Service (IaaS) - In this case, computing resources (compute, storage, and network) are exposed as a capability.  Instead of owning, managing or controlling the underlying infrastructure, you rent the infrastructure, as a service.  An example is  Amazon Elastic Cloud Compute (EC2).
    • Platform as a Service (Paas) - In this case, programming platforms and tools (such as java, python, or .NET) and/or building blocks and APIs for building cloud-based applications and services are made exposed as a capability.  Examples include Amazon Simple Storage Service (S3), Azure Storage, and Force.com.
    • Software as a Service (SaaS) – In this case, applications are exposed as a service running on a cloud infrastructure.  Examples include SalesForce.com and Microsoft Office Online.

    For my related posts on cloud, see:

  • J.D. Meier's Blog

    Visual Model of Cloud Computing

    • 0 Comments

    “All models are wrong, some are useful.” – George Box

    This is a simple visual model we’re using on our patterns & practices Azure Security guidance team to dialogue around cloud computing concepts. 

    VisualModelOfCloudComputing 

     

    Here are the key things to know:

    1. Characteristics are simply the three key characteristics we defined for our working definition of cloud (see Cloud Defined.)
    2. Service models includes the options Software as a  Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS) models.
    3. Deployment  includes the options on-premises, off-premises, and hybrid, which is a combination of on-premises and off-premises.

    Aside from providing a simple lens for looking at cloud computing, this model also helps us find important or interesting intersections across various cloud efforts in the industry.  For example, this can help us connect the dots to  NIST’s cloud computing work.  We can find useful intersections at a model level, without getting lost in the weeds.

  • J.D. Meier's Blog

    Cloud Defined

    • 1 Comments

    “Nature is a mutable cloud which is always and never the same.” – Ralph Waldo Emerson

    It’s tough to talk about clouds until we have a simple, working definition.  While ramping for Azure Security guidance, we defined the cloud as follows:

    A cloud is a managed infrastructure providing network, compute, and storage capabilities.   It has the following 3 key characteristics:

    1. Managed / abstracted infrastructure
    2. Elastic resources
    3. Pay-for-play / utility computing

    This simple frame helps us identify what is cloud, and what is not.

    That’s not the only definition in town though.  Here are a few others that I found useful ...

    Berkeley Cloud Definition
    In Above the Clouds: A Berkeley View of Cloud Computing, U.C. Berkeley Reliable Adaptive Distributed Systems Laboratory define the cloud as follows:

    “Cloud Computing refers to both the applications delivered as services over the Internet and the hardware and systems software in the datacenters that provide those services. ... From a hardware point of view, three aspects are new in Cloud Computing.

    1. The illusion of infinite computing resources available on demand ...
      users to plan far ahead for provisioning.
    2. The elimination of an up-front commitment by Cloud users ...
      increase hardware resources only when there is an increase in their needs.
    3. The ability to pay for use of computing resources on a short-term basis as needed ...”

    In A Break in the Clouds: Towards a Cloud Definition
    In A Break in the Clouds: Towards a Cloud Definition, Vaquero et al define cloud as follows:

    “Clouds are a large pool of easily usable and accessible virtualized resources (such as hardware, development platforms and/or services). These resources can be dynamically re-configured to adjust to a variable load (scale), allowing also for an optimum resource utilization. This pool of resources is typically exploited by a pay-
    per-use model in which guarantees are offered by the Infrastructure Provider by means of customized SLAs.”

    What’s your working definition of “cloud” that you’ve found helpful?

  • J.D. Meier's Blog

    Mapping Out the Microsoft Application Platform at a Glance

    • 12 Comments

    “People only see what they are prepared to see.” - Ralph Waldo Emerson

    At the beginning of the year, I like to take a quick survey of the Microsoft application platform.  It helps me figure out where to put my bets and where to explore.  It’s a “see the forest, from the trees” exercise.

    And oh, what a forest it is.  The beauty is it covers a wide spectrum and supports so many scenarios.  The challenge is finding your way around.  To find my way around, I map out the platform and I think in terms of application types:

    • Web applications
    • Mobile applications
    • Rich Internet Applications (RIA)
    • Rich Clients
    • Web Services

    By thinking about deployment targets such as cloud or desktop or browser or phone, etc. it makes it very easy to get in the ballpark in terms of context and technologies very quickly.  From there, I can worry about things like presentation or data access stacks or language platforms (native, .NET, or scripting.)   It’s also a quick way to explore relevant quality attributes (security, performance, reliability) or evaluate architectural styles.  In other words, it’s a way to hack through information overload and cut to the chase.

    Microsoft Application Platform at a Glance
    This is my draft map of the platform.   It’s a strawman that I use to walk the platform, find clusters of technologies, figure out what’s changed, and evaluate the latest story.  It’s easier for me to have conversations about the platform with customers or product teams when I start with a shared frame.  The hard part is putting the initial map together.  The easy part is improving it through feedback.  If something is missing, it’s easy to add.  If something is wrong, it’s easy to fix.

    As simple as the map looks, it compacts a lot of information.  I stuck the code names in where I could find them.   Enjoy …

    Category Items
    Application Infrastructure
    ALM (Application Life-Cycle Management)
    App Frameworks / Extensions
    Cloud
    Collaboration / Integration / Workflow
    Data Access
    Database Server
    Development Tools
    Games
    Identity
    Languages

     

    Mobile
    Modeling
    OBA (Office Business Applications)
    Parallel
    Rich Client
    Rich Internet Applications (RIA)
    Services
    Web
    Web Server
    Windows Server

    Where To Find Out More
    I’m a fan of teaching people to fish, as well as giving some starter fish.  Aside from people, events, and social media, the three best ways I know to figure out what’s happening on the platform are Wikipedia, Channel9, and the MSDN Dev Centers.  I started you out with some pages below …

    Wikipedia

    Channel9 Training Centers

    MSDN Dev Centers

Page 1 of 1 (7 items)