This event brings together IT executives from the region, including CIOs, CTOs, CISOs, and VPs. Conference agendas are driven by CIOs and senior IT executives. The goal of the forum is to create an encouraging atmosphere to help solve technology, leadership and business challenges. 

RDA is hosting the following breakout session:

Can big data be housebroken? Getting the animal to do what you want and need.
Many companies are undertaking “Big Data” initiatives.  How do these initiatives align with business opportunities and challenges?  What processes should be put in place to reinforce this alignment?  Don’t get lost in the hype.  Big Data is not just about the Volume, Variety, and Velocity of data but most importantly the Value – the ability to analyze and act on data. This panel discussion will examine how other companies are making their big data actionable and how they overcame the challenges and obstacles that stood in their way.

Get details on this event.

Image Source

In this 4-part blog series we will look at a few of these new features and changes. This list is by no means inclusive (that takes a lot more space than we have) and does not cover more technical topics such as the new authorization/security model, apps, and various developer enhancements. For a more complete list, please visit What’s New in Microsoft SharePoint Server 2013.

Social Computing

SharePoint 2013 includes new functionality for sharing and collaboration as well as improved administration and user experiences.

Communities

Many users of SharePoint 2010 utilized the Discussion list template to facilitate discussions among members of a site. SharePoint 2013 builds on this concept through the introduction of two new site templates: the Community Site and the Community Portal.

Community sites provide the user with a forum to categorize and facilitate discussions with a broad group of people across the entire enterprise by promoting open communication and information exchange among users. Visitors can view information and can choose to become members if they wish to contribute.

As you would expect, full moderation capabilities are included, such as the reporting/removal of inappropriate content, selecting featured content, and assigning of various badges to community members.

My Sites

In SharePoint 2010, My Sites became a central place for users to store personal and shared documents of many types. Through the use of people search, users were able to populate their profile with information to promote connections with other users, thus benefiting from the expertise of others within the organization.

In SharePoint 2013, the My Sites interface has been completely re-designed to enhance the capabilities provided with the previous release,  including simplified navigation and new Microblog and Newsfeeds features. These features allow users to engage in short, public conversations, and to remain current on activities from other users that they find interesting.

The fun is just beginning! In my next post, we will take a look at SharePoint 2013′s content authoring and mobile device support features. See you there!

Image Source

This event brings together IT executives from the region, including CIOs, CTOs, CISOs, and VPs. Conference agendas are driven by CIOs and senior IT executives. The goal of the forum is to create an encouraging atmosphere to help solve technology, leadership and business challenges.

RDA is hosting the following breakout session:

Can big data be housebroken? Getting the animal to do what you want and need.
Many companies are undertaking “Big Data” initiatives.  How do these initiatives align with business opportunities and challenges?  What processes should be put in place to reinforce this alignment?  Don’t get lost in the hype.  Big Data is not just about the Volume, Variety, and Velocity of data but most importantly the Value – the ability to analyze and act on data. This panel discussion will examine how other companies are making their big data actionable and how they overcame the challenges and obstacles that stood in their way.

Get details on this event.

Image Source

WCF services are a staple of multi-tiered architectures because they make it easy to move business logic or data operations into a service without having to worry much about the process that is hosting it, the transport, message formats, etc.  The abstraction is so clean in fact, that I’ve actually spoken with developers who didn’t even realize that their code was running in a different process (or possibly on a different server altogether).  This can be a both good thing and a bad thing.

Let’s say that you have an existing ASP.NET application that is using Entity Framework for data access, and all the code runs within this ASP.NET application.  Later you decide that it’s time to move your data access into a WCF service, so you create a new service project (with the default bindings and message format), and begin porting your code into your new service.  For the most part everything just works, you barely broke a sweat, and life is good.

Although your code probably compiles after only a few tweaks, most of the time you are going to run into at least a handful of serialization issues related to the parameters or return types of your service methods.  And because these are run-time serialization exceptions (which are in some cases data-dependent), you may not even notice there is a problem until you’ve deployed your service and are exercising it with real data.  This is the part that can be a little confusing if you are new to WCF or service-oriented applications in general.

This post is about common serialization issues that you are most likely to encounter when porting existing code to a WCF service or when leveraging legacy data models in a new project.  We’ll wrap up with a simple approach you can use in your unit tests to ensure that new serialization bugs aren’t introduced down the road.

Classes with Circular References

Most object models have at least some circular references.  For example, a parent object has collection of children, and each of those child objects holds a reference to the parent.  This can pose a problem to a framework that uses text-based messages to represent those models.

Consider the following:

    [ServiceContract]
    public interface IService1
    {
        [OperationContract]
        List GetEmployees();
    }

    [DataContract]
    public class Employee
    {
        [DataMember]
        public string Name { get; set;}
        [DataMember]
        public bool IsActive { get; set; }
        [DataMember]
        public Employee Manager { get; set; }
    }

Each employee object holds a reference to another Employee object (Manager). To illustrate, let’s implement the GetEmployees() method with some sample data:

    public class Service1 : IService1
    {
        public List GetEmployees()
        {
            var jon = new Employee()
                { Name = "Jon", IsActive = true };
            var steve = new Employee()
                { Name = "Steve", IsActive = true, Manager = jon };
            var mike = new Employee()
                { Name = "Mike", IsActive = false, Manager = steve };

            return new List() { jon, steve, mike };
        }
    }

If we deploy and run this it works great, and this scenario seems harmless.  But what if in reality we end up with a condition where the data has a circular reference?  I realize that this is a contrived example, but for the sake of brevity, let’s make one quick change to the code above:

        public List GetEmployees()
        {
            var jon = new Employee()
                { Name = "Jon", IsActive = true };
            var steve = new Employee()
                { Name = "Steve", IsActive = true, Manager = jon };
            var mike = new Employee()
                { Name = "Mike", IsActive = false, Manager = steve };

            jon.Manager = mike;

            return new List() { jon, steve, mike };
        }

The code will still compile and deploy, but when we call the service method over a WCF channel we’ll get an exception:

“Object graph for type ‘Employee’ contains cycles and cannot be serialized if reference tracking is disabled.”

Fortunately, this common problem has an easy fix.  We just need to set the “IsReference” property on the DataContractAttribute to tell the serializer to serialize the objects as references.  Note that there is a small performance penalty for doing this (so only use it when necessary), and it will only work with XML message formats, but it allows us to salvage our existing data model without major refactoring.

    [DataContract(IsReference=true)]
    public class Employee
    {
        [DataMember]
        public string Name { get; set;}
        [DataMember]
        public bool IsActive { get; set; }
        [DataMember]
        public Employee Manager { get; set; }
    }

Derived Return Types

Let’s assume that some employees are hourly employees that require a special derived class, which again would be a very common thing to find in your object model. Let’s add an HourlyEmployee class that derives from Employee, and modify our GetEmployees() method to make use of it in our sample data:

    [DataContract(IsReference = true)]
    public class HourlyEmployee : Employee
    {
    }
    public List GetEmployees()
    {
        var jon = new Employee()
            { Name = "Jon", IsActive = true };
        var steve = new Employee()
            { Name = "Steve", IsActive = true, Manager = jon };
        var mike = new HourlyEmployee()
            { Name = "Mike", IsActive = false, Manager = steve };

        jon.Manager = mike;

        return new List() { jon, steve, mike };
    }

As soon as we encounter this new type after deploying the service and calling the method we will get a serialization exception:

“Type ‘HourlyEmployee’ with data contract name ‘HourlyEmployee:http://schemas.datacontract.org/2004/07/WCFSerialization’ is not expected.”

Again this is an easy fix.  We just need to modify the data contract of the Employee type to allow the HourlyEmployee type as well.  We do this by adding the KnownTypeAttribute:

    [DataContract(IsReference=true)]
    [KnownType(typeof(HourlyEmployee))]
    public class Employee
    {
        [DataMember]
        public string Name { get; set;}
        [DataMember]
        public bool IsActive { get; set; }
        [DataMember]
        public Employee Manager { get; set; }
    }

Non-Serializable Collections

Certain types of collections can’t be serialized and should never be used as members in your data model.  For example, IQueryable<T> can’t be serialized, but if you need to provide an IQueryable<T> member on your class, you can implement it as a wrapper for another (optionally private) collection that can be serialized.  Just be sure to mark it with the IgnoreDataMemberAttribute so that the serializer will ignore it.

    [DataContract(IsReference=true)]
    [KnownType(typeof(HourlyEmployee))]
    public class Employee
    {
        [DataMember]
        public string Name { get; set;}
        [DataMember]
        public bool IsActive { get; set; }
        [DataMember]
        public Employee Manager { get; set; }

        [DataMember]
        private ICollection _directReports { get; set; }

        [IgnoreDataMember]
        public IQueryable DirectReports {
            get { return _directReports.AsQueryable(); }
            set { _directReports = value.ToList(); }
        }
    }

Another common issue is with collections that are marked as virtual and get overridden with a type that is not expected by the serializer.  This is similar to the KnownType issue above, but they are usually anonymous types that can’t be accounted for at design time.  You will most frequently see this with ORM tools (such as Entity Framework) where virtual collections are used as a mechanism to support lazy loading.  Obviously you can’t lazy load a collection that has already been serialized and returned to the client, so lazy loading should just be disabled.  The approach for doing this varies according to the specific framework and version you are using, but for Entity Framework you can find more information here.

Unit Testing for Serialization Issues

Up until now we’ve discussed problems you might discover after you’ve deployed your WCF service.  But how do we catch serialization errors before we’ve deployed our code?  You can write integration test scripts that will automatically deploy and test your service, but setting that up can be tricky and time-consuming.  As an easier alternative, you can leverage the DataContractSerializer directly in your unit tests.  The basic approach is to call your service methods directly, and then serialize and deserialize the result to simulate the process that is normally handled by WCF.

While I’m sure it’s not bullet proof, I’ve used this approach many times, and it will catch all of the scenarios discussed above.  First, add a unit test project to your solution.  Then simply create some serialization helper functions that you can from each of your tests.  I’ve included a stripped-down version (below) that can be used as a starting point.

using Microsoft.VisualStudio.TestTools.UnitTesting;
using System.Text;
using System.IO;
using System.Runtime.Serialization;
using System.Xml;
using System.Collections.Generic;

namespace UnitTestProject1
{
    [TestClass]
    public class UnitTest1
    {
        [TestMethod]
        public void TestMethod1()
        {
            var service = new Service1();
            var employees = service.GetEmployees();

            //include any business logic tests
            // { ... }

            //test serialization
            string xml = employees.SerializeToXml();
            List employee2 = xml.DeserializeObject>();
        }
    }
    public static class SerializationHelper
    {
        public static string SerializeToXml(this object obj)
        {
            var dataContractSerializer = new DataContractSerializer(obj.GetType());
            using (var memoryStream = new MemoryStream())
            {
                dataContractSerializer.WriteObject(memoryStream, obj);
                return Encoding.UTF8.GetString(memoryStream.ToArray());
            }
        }
        public static T DeserializeObject(this string xml) where T : class
        {
            MemoryStream memoryStream = new MemoryStream(Encoding.Unicode.GetBytes(xml));
            XmlDictionaryReader reader =
                XmlDictionaryReader.CreateTextReader(memoryStream, Encoding.Unicode,
                new XmlDictionaryReaderQuotas(), null);

            DataContractSerializer dataContractSerializer =
                new DataContractSerializer(typeof(T));
            return dataContractSerializer.ReadObject(reader) as T;
        }
    }
}

Please contact RDA for “Architecture and Code Analysis” of your application.  We can ensure that your application’s design and code follow best practices, and we can make recommendations for making your design faster, more scalable, and more secure.  We can also help make your legacy applications mobile-ready or cloud-ready. Happy Coding!

Image Source

The conference tracks are designed for IT Executives, Project Managers / Managers, IT Professionals, Developers and Business Leaders and are delivered by Microsoft’s top national and local partners.

We are sponsoring the event and RDA Senior Consultant Greg Robinson will present on “Manage, Search, and Socialize Institutional Knowledge.”

Register to attend.

GR8 SharePoint Conference
Thursday, May 2, 2013
King of Prussia / Philadelphia

Get the details.

If you cannot attend but would like to be notified when the conference content is available, please click on the link below and the organizers will send you the links to the content as it becomes available.

No, I Cannot Attend (Send me the links to the content)

We hope to see you there!

Image Source

What is social engineering?

A con man is a social engineer.  He makes use of his knowledge of human nature to manipulate others into taking actions they otherwise would not have taken.  Trickery, flattery, exploitation of greed, bestowing of gifts and more can be used to drive the behavior of others in startlingly predictable ways.

Kevin Mitnick, an ex-hacker and computer security expert, has spoken extensively about how he was always more successful with social engineering than with traditional hacking.  It makes sense when you consider that it’s generally easier to convince someone to give you a password than it is to discover and exploit a technical security flaw.  Indeed, recent studies have shown that many people will give up their passwords for trivial gifts such as pens or chocolate bars.

In this post, I’ll explain some common social engineering techniques and demonstrate how businesses can protect themselves from such techniques.

Pretexting

Almost all social engineering schemes make use of pretexting, which refers to the creation of a contrived scenario used to set the stage in such a way that a victim is more likely to give up information or perform inappropriate actions.  Consider the following scenarios:

• I’m calling from the Internet security bureau to inform you that your PC is infected with a dangerous computer virus. <Said with an authoritative tone>  Federal law requires that you disinfect your PC immediately by visiting MaliciousWebsite.com…
• My Wife/Father/Brother/Dog just died! <sobbing> I need to reset his email password to pay the bills and keep the lights on! Can you please help me?
• I’m calling on behalf of the “<Your Company> Gives Back” campaign.  We are collecting donations for victims of <recent natural disaster>.  We can deduct your donation from your paycheck directly!  Would you like to give $10? Great, I’ll just need your password for verification…

The above scenarios certainly play on the victims’ naiveté, but also their respect for authority, empathy for the grieving, and desire to help others in need.  By contriving such scenarios, a social engineer can be very successful in extracting information or getting others to perform inappropriate actions.

Phishing

Phishing refers to the practice of corresponding with a large number of people under the guise of a known entity (business or government agency) in an attempt to extract personal information such as social security numbers or passwords.  Some of those people will inevitably believe that the correspondence is real and respond accordingly, with personal information.

Note that phishing can be accomplished with any form of correspondence.  We typically associate phishing with email, because it is relatively simple to send thousands of emails, and it’s easy to provide a link to a malicious website within an email.  But phishing attacks can take place over traditional mail, telephone, web chat, or other mediums.  When an attacker makes use of an automated IVR (interactive voice response) system, it is known as IVR phishing.  These days, it is very simple to create automated telephone systems, so people should never trust a seemingly legitimate phone system unless they called the system itself using a known telephone number.

Most phishing that occurs is email based, and it generally follows this pattern:

• User gets a message from <Big Bank> saying they must validate their personal information due to “anomalous activity” detected on their account (note the pretext – the target is frightened into thinking someone ELSE is trying to get to their money!)
• User clicks the login link in the email, which actually goes to a malicious website that is dressed up to look just like the website at <Big Bank>
• User types in their username and password and clicks “log in”
• User is asked to “verify” additional information by typing in their social security number, mother’s maiden name, etc…

At this point, the attacker knows enough about you to take over most of your accounts at various businesses.  Through the use of additional social engineering, he may be able to get access to your phone records, take out loans in your name, and more.

Note that even the savvy can be taken in when phishing techniques are combined.  Many people might think to check the URL in the link to log in at <Big Bank>, and notice that it doesn’t actually go to <Big Bank’s> website.  If there was a phone number in the email instead (probably with a message like: “to protect your security, avoid the dangers of online access and call this number”), many people wouldn’t question dialing that number. When they hear a very professional-sounding IVR phone system with menu options and voice recognition, they may be fooled into believing the lie entirely.

Baiting

Baiting refers to a method of installing a malicious device onto a protected PC or network.  Baiting works by disguising the device as something that your target would want to plug into their PC and leaving it somewhere that the target could find it.

The classic example is a USB drive (or better, a dozen USB drives) loaded with malware and dropped randomly around a corporate office’s parking lot.  Many people, simply out of curiosity, will pick up and plug in those drives to see what they might contain.  An attacker can up the ante by labelling a drive or disk to increase curiosity, or even let greed do its work.  A CD drive labelled “Quarterly Earnings Q1 2013” (found before earnings were made public) might be fairly effective in exploiting a target’s greed, for example, or perhaps a good Samaritan will return the disk to the company (where it will be promptly inserted into a drive).

Of course, most PCs these days have auto-run disabled, so users would have to unwittingly execute a file off the disk in most cases, but this can be encouraged by disguising the executable as an interesting document, for example.

With more sophistication, baiting can become very difficult to resist, especially when people are unaware that they might be targeted in such a way, as many undoubtedly are.  For example, imagine you have “won” a prize that comes to your mailbox one day.  Perhaps this prize is a digital music player with malware on it.  Maybe it is Christmas time and the prize is a mini tree with lights (USB powered, of course, with malware included).  It is even possible to embed wifi capabilities into such devices and use them as wireless backdoors into a private network.

Miscellaneous Types of Social Engineering

Quid Pro Quo

Quid pro quo is exactly what it sounds like.  An attacker offers his victim a gift in exchange for some action or piece of information.  As mentioned above, this is surprisingly effective according to a variety of studies.  The attacker often does not even need to make a deal.  By simply providing assistance in some way, an attacker can endear themselves to their victim, making further interrogation a simple matter.

Tailgaiting

Tailgating refers to the actions of people who do not have a security badge or access to a particular physical space, but get in to that space regardless by closely following someone who does have access.  As a consultant who doesn’t always get a security badge when visiting clients, I can sadly say that I have personally mastered this technique.  Even though most people are trained to disallow tailgating, in practice many are too timid to confront a potential tailgater.  This is one reason why some companies require its employees to display their badges in a visible place.  If many people keep their badges concealed, it is practically impossible to enforce a no-tailgating policy.

Dumpster Diving

Dumpster diving refers to the practice of looking through trash for sensitive information.  A tried and true technique used by spies and personal investigators for a very long time (perhaps since the dawn of paper records), companies are generally well aware of the need to dispose of sensitive trash securely, and an entire industry has been created for this very purpose.

Protecting Yourself and Your Business

A number of common sense rules must be followed by everyone within an organization to keep it safe:

• Always verify the identity of any person or system to whom you are providing personal or sensitive information.
• Never take actions or divulge others’ sensitive information without obtaining the required prerequisite identifying or authorizing information (no exceptions!).
• Never plug in a device to your PC or network that is not known to be safe.  Note that USB drives have been known to come from the factory with malware installed and should be heavily discouraged if enabled at all.
• Destroy sensitive trash before disposal.
• Politely refuse unknown tailgaters.
• Remember that a person’s backstory or nice gift does not mean you can trust that person.

Unfortunately, those rules are not enough, as they do not specify what is “sensitive” or what the “prerequisite” identifying info must be.  For that, you must create a “framework of trust” for your organization which defines the following items:

• Which information is considered sensitive
• Who has access to that information
• How they access that information
• The acceptable ways they may share that information
• The ways another party may be authorized to access that information
• What is acceptable and required identifying information

In addition to defining those items, this framework must be tested periodically without warning.  When found, irregularities should be investigated and corrective action should be taken.

Finally, keep this in mind next time you call helpdesk or a business you have an account with.  Are they properly verifying your identity before taking action?  If not, ask to speak with a supervisor and alert them of the problem.  Remember that insecure businesses put YOU at risk, too.

In my next post, I’ll discuss password security and why we need to rethink what makes a password “secure.”

Image Source

To set the stage, this post will provide a summary of just a few EA features that can be used to manage information more easily than in traditional free-form documents. Of course, any tool you use will have to be adapted to meet your organization’s needs. For example, smaller projects with co-located teams will require much less documentation than efforts that are complex with large, distributed teams. The key is to document what is needed and nothing more, which is also referred to as JBGE (Just Barely Good Enough).

EA Demonstration

The agile requirements begin with a set of user stories which can be drilled into for further details. This allows each viewer to navigate to the level of details that are pertinent to his or her needs. For example, developers may need all of the specific details, whereas a project manager may want to just see the dependencies between user stories.

This drillable diagram below consolidates multi-level process flows into a single document and also allows for the capture of textual information, which can be cumbersome to author in a word processing document. Almost any object can be opened into a more detailed format where further information is captured.

The icon circled below represents a wireframe that can be opened to display a picture of how the system should look. By placing this within the diagram, a team member can view these details as they navigate through the process flow, instead of referencing multiple documents or scrolling top to bottom.

The wireframe is interactive, too. For example, specific requirements like field validation could be included in a detail form. There is also a Keywords field which makes this asset searchable across the entire file. This can be useful to group common concepts across functional areas of the design.

—

A glossary also provides for centralized management of business terms that will automatically be propagated to other areas of the document where they were used. This prevents having to perform a “find and replace” across multiple documents stored in numerous areas.

The value addition of this toolset gives the agile project team a formal way to document the design without getting bogged down by numerous documents that start to feel like traditional waterfall methods. This is especially important for large, distributed teams that are solving complex problems. It allows everyone to consume the needs of the business as-needed and apply the necessary updates easily in the EA objects. The level of usage of this tool should be consistent with “Just Barely Good Enough” documentation, so that it won’t become a burdensome task that is common with waterfall or agile teams that have not figured out how to utilize a lean documentation process.

For additional resources related to custom application development and architectural guidance, please visit our resources page.

Image Source

RDA President and CEO Tom Cole said, “The workflow and forms products Nintex has developed will enhance the SharePoint solutions we deliver to our customers. Nintex is a great fit for RDA and our clients. I’m looking forward to the opportunities our partnership will create.”

“Nintex sees the value RDA can bring to the utilization of our technology solutions to create impactful and transformative change for organizations. We are excited about their inclusion to our Partner Network and our ongoing work together,” says Brett Campbell, Vice President, Alliances, Nintex.

Learn more about Nintex. 

This blog post examines the challenges faced when extracting data from a VLDB and offers an enhanced approach to extracting data from the VLDB via the use of SQL Server 2012′s “AlwaysOn” feature.

What are Very Large Databases?

Very large databases are databases that are at least one terabyte in size.  Databases that have a high volume of transactions are not necessarily considered VLDBs but the volume of data being added to the database can be a major factor in the creation of a VLDB.  Other possible ways of a VLDB being created include but are not limited to:

• Large datasets
• Acquisitions
• Consolidation of previously silo’d departmental/business unit databases
• Regulations and or business requirements that require companies to maintain historical data (e.g. Finance, HR)
• Poor database design
• Non-existent or inefficient data archival processes

As the size of the database grows, the number of data pages within the database also increases and this leads to a number of performance challenges within the database.  First, the data reads and writes (inserts, updates, deletes) performed within the VLDB take longer to complete when compared to non-VLDBs.  Secondly, database operations such as writing and reading rows involve a greater number of data pages, and so have a higher probability of taking longer to complete, which increases the likelihood of issues with database contention.  Lastly, regular and necessary database administrative functions such as backups and index maintenance activities consume relatively more resources (CPU, storage, and memory) when compared with non-VLDBs.  Hence, mechanisms for extracting data from a VLDB (such as Extract, Transform and Load programs) are often viewed as increasing the performance problems within the database.

What are ETL programs?

The picture below shows the architectural components of a simple BI solution.  An ETL (Extract, Transform, and Load) program is a process or set of processes that are utilized as the mechanism that a business uses to copy data from its OLTP system to the data store(s) (such as a data mart) that are directly accessed by the BI solution.

What is SQL Server’s AlwaysOn?

Built on the Windows Server Failover Clustering service, SQL Server’s AlwaysOn feature offers High Availability (the percentage of time that the database is expected to be available within a specific period of time such as a month quarter or year) and Disaster Recovery (the capability of resuming operations following a planned or unplanned system failure) solutions for businesses.  The feature is available with SQL Server 2012 Enterprise and Developer editions and addresses the limitations of earlier versions of SQL Server.

Previous versions of SQL Server offered high availability and disaster recovery solutions primarily via database mirroring and log shipping.  These solutions had problematic limitations such as one-to-one mapping between servers, non-zero data loss and manual failovers.  Additionally, because the secondary servers within the solutions were at times not readable, this led to situations in which database servers were unused or underutilized. 

Aside from the direct benefits of high availability, disaster recovery and increased utilization of enterprise information technology resources such as database servers, the AlwaysOn feature provides businesses with ability to execute backups, reports, ad hoc queries and ETLs against a replica of the transactional database.

With AlwaysOn, businesses can create four secondary replicas for each primary replica.  However, only two replicas can be configured to use the synchronous-commit mode.  The available data synchronization modes are listed below:

• Synchronous-commit mode: transactions committed to disk on both the primary and secondary databases.
• Asynchronous-commit mode: transactions committed on the primary replica without being committed on the secondary replica.

An Enhanced ETL

The picture shows a modified BI solution design that uses a readable secondary replica as the data source for the ETL processes.  Within the design, the secondary replica has been configured for asynchronous commit mode to allow transactions to be committed on the primary replica without waiting for the transactions to be applied to the secondary replica.

To use AlwaysOn, create an Availability Group that has a readable secondary replica configured for asynchronous-commit, set the connection mode set to “Allow all connections,” create and configure the Availability Group listener, and modify the database connection(s) used by the ETLs to include the listener port, name and an ApplicationIntent=ReadOnly attribute.

The major benefits of ETLs using SQL Server 2012’s AlwaysOn include a reduced likelihood of database contention on the primary replica.  With less database contention, VLDBs are expected to have improved performance of mission critical database processes and related applications.  Additionally, ETLs that are executed against a secondary replica can be executed more frequently. Their performance is also significantly improved, and the latency of the data available within the BI solution decreases. The increased performance of ETLs within the secondary replica stems from the temporary statistics that are built on the secondary databases and the use of row versioning via snapshot isolation transaction level.

Businesses that have at least one VLDB can benefit from the SQL Server AlwaysOn feature in a number of ways that results in the improved performance of both the VLDB and the BI solution by leveraging secondary replicas that serve the purpose of being the source of the ETLs that are used to move transactional data to the data stores that are used by the BI solution.  This approach allows the ETLs to execute efficiently without impacting the businesses’ critical transactional databases.

For additional information related to business intelligence and SQL Server, I invite you to explore the many resources available on our BI Thought Leadership page.

Image Source

6. Don’t Trust Services / Don’t Trust Infrastructure

External or 3^rd party services are services that are not under your direct control.  When designing a system to interact with these services, it’s important not to trust these services in such a way that would allow the services to affect your system in unexpected ways, should the service behavior change in some way.  To do this, design your service interactions for security, validate all service data (so that a datatype change doesn’t break your code, for example) and ensure that all code interacting with external services fails securely.  We must also ensure that we aren’t exposing any more information to these services than is absolutely necessary.  If using an external service to store user-related data, for example, we might encrypt the data and use an alternate identifier (other than the username) to retrieve this data.

Another side of this principle is that even your infrastructure cannot be considered secure. This is why credit card information must be securely encrypted, for example, as otherwise everyone from system administrators to datacenter janitors would have easy access to this information.  Another example is the assumption that internal network traffic must be secure.  There is no guarantee of that, so appropriate transport level encryption and authorization should be used, even within your network.

7. Separation of Duties

Although separation of duties is an honored system design principle, in the context of security we are specifically referring to three specific duties:

• Provide authorization to perform an action
• Perform an action
• Monitor that an action was performed and by whom

By ensuring that distinct mechanisms perform each of the three duties above whenever a system performs a secured action, we make it more difficult for an attacker to carry out and conceal prohibited activity.  Curiously, this principle applies more to the process in which we administer applications (approving, acting upon and monitoring a system change are typically done by distinct parties) and manage the software development lifecycle, than it does to our application design itself.  For example, it is more secure to have each “action” have a form of embedded authorization, rather than implement that authorization at a different level of your code.  This way, any calls to that “action” will be checked for authorization, regardless of the code path used to get there.  On the other hand, from a design perspective, it’s important that your authentication (not authorization) and logging functionality be logically separated.

8. Avoid Security by Obscurity

Simply put, you should assume that hackers have a copy of your source code.  This is because with a properly designed secure system, there is no need for obscurity except for the unique case of keeping encryption keys a secret.  In fact, this argument has been used extensively to argue for the enhanced security of open source software.

Of course, for most custom applications, releasing source code in the open would be unwise, simply for the reason that as humans, we make mistakes, and almost every complex application has security holes of one kind or another.  Applying the principle of defense in depth, however, allows us to assume the source code is publicly available and that we should design our systems not to rely on obscurity in any way.

Security by obscurity abounds, however.  It is present in many, many applications, and is typically the result of hurried development, inattention, or laziness.  Not securing URLs because they aren’t publically known?  As soon as someone browses that URL from a public computer or on an open wifi network, that URL can be known.  Using insecure cookies for authorization because, hey, who would notice?  It takes very little effort to see and change cookies within a browser session.

Anytime you design or code an application and think “but no one would think of that!” relating to bypassing security of some sort, you should step back and consider an alternative design.  Relying on any kind of “secret” (with the exception of encryption keys) about how an application functions is a big no-no.

9. Keep Security Simple

This is the equivalent of the KISS (keep it simple, stupid) principle for security.  It applies to all levels of application design, from the overall capabilities of the system to the specific code structure of security related code.  In general, a simple system is easier to understand and control, therefore reducing overall security risks and ensuring that modifications to security related code are less likely to create new security holes.

I have seen systems with highly coupled (spaghetti) and poorly structured security code which was very difficult to maintain.  In one case, the code path for user account updates was dependent on the current stack trace details!  Needless to say, this is not best practice (you might consider it “worst practice” in fact).  In that case, a serious vulnerability allowing anyone to take over any existing user’s account was discovered, but only by someone testing the software after the code had been running in production for over a year.  It turns out that the vulnerability was introduced by a seemingly simple change made during maintenance of the security code.  The complexity of the code structure made it very difficult to predict this vulnerability would result from the change.  For this reason, a clean and simple code architecture that can be easily traced is essential for security related code.

Sometimes this principle applies to the level of features and functionality offered by the system to begin with.  For example, Skype recently encountered a problem where user accounts were vulnerable to being taken over by 3^rd parties.  Without getting into too much detail, the issue had to do with the fact that Skype allowed users to associate their user accounts with multiple email addresses and perform password resets in such a way that allowed 3^rd parties to take over any Skype account simply by knowing the users’ associated email address.  Skype had to disable password reset entirely until a solution to the problem was put in place.  This is an example where the combined complexity of multiple emails per account and password reset options created a vulnerability that was very difficult to detect.  Looking back, it’s clear that this complexity is probably unnecessary to begin with, and that a simpler system wouldn’t have encountered this problem in the first place.

10. Fix Security Issues Correctly

As mentioned when discussing keeping security simple, it is very easy to introduce security holes while maintaining security related functionality.  For this reason, it’s essential that security related code be maintained with great care, and that when we do find and fix security holes, we must fix them correctly and be sure that we don’t introduce new security holes.

I recommend mandatory code review sessions for modifications to security related code whenever possible.  As with open source software, more eyes on the code will result in a more thorough vetting than any individual programmer can provide.  Also, as mentioned in the Skype example, you may need to disable functionality altogether (as Skype did with the reset password function) until it can be properly secured.

Stay tuned for the next post in this series: “Social Engineering:Your Biggest Security Threat,” where I will discuss the methods of social engineering that make systems vulnerable, and how to guard against them.

Image Source