Putting the I Back into Infrastructure

Tonight at the IT Pro Toronto we did a pre-launch of the Infrastructure 2010 project.  Have you ever been in a position where you just don’t have a clear grasp of a concept or design?  It’s not fun.  As a result, CIPS Toronto, IT Pro Toronto, and TorontoSQL banded together to create a massive event to help make things a little more clear.  To give you a clearer understanding of how corporate networks work.  Perhaps to explain why some decisions are made, and why in retrospect, some are bad decisions.

Infrastructure 2010 is about teaching you everything there is to know about a state-of-the-art, best practices compliant, corporate intranet.  We will build, from the ground up, an entire infrastructure.  We will teach you how to build, from the ground up, an entire infrastructure.

Sessions are minimum 300 level, and content-rich.  Therefore:

i2010Proud[1]

Well, maybe.  (P.S. if you work for Microsoft, pretend you didn’t see that picture)

Security, Security, Security is about Policy, Policy, Policy

The other day I had the opportunity to take part in an interesting meeting with Microsoft. The discussion was security, and the meeting members were 20 or so IT Pro’s, developers, and managers from various Fortune 500 companies in the GTA. It was not a sales call.

Throughout the day, Microsofties Rob Labbe and Mohammad Akif went into significant detail about the current threat landscape facing all technology vendors and departments. There was one point that was paramount. Security is not all about technology.

Security is about the policies implemented at the human level. Blinky-lighted devices look cool, but in the end, they will not likely add value to protecting your network. Here in lies the problem. Not too many people realize this -- hence the purpose of the meeting.

Towards the end of the meeting, as we were all letting the presentations sink in, I asked a relatively simple question:

What resources are out there for new/young people entering the security field?

The response was pretty much exactly what I was (unfortunately) expecting: notta.

Security it seems is mostly a self-taught topic. Yes there are some programs at schools out there, but they tend to be academic – naturally. By this I mean that there is no fluidity in discussion. It’s as if you are studying a snapshot of the IT landscape that was taken 18 months ago. Most security experts will tell you the landscape changes daily, if not multiple times a day. Therefore we need to keep up on the changes in security, and any teacher will tell you, it’s impossible in an academic situation.

Keeping up to date with security is a manual process. You follow blogs, you subscribe to newsgroups and mailing lists, your company gets hacked by a new form of attack, etc., and in the end you have a reasonable idea of what is out there yesterday. And you know what? This is just the attack vectors! You need to follow a whole new set of blogs and mailing lists to understand how to mitigate such attacks. That sucks.

Another issue is the ramp up to being able to follow daily updates. Security is tough when starting out. It involves so many different processes at so many different levels of the application interactions that eyes glaze over at the thought of learning the ins and outs of security.

So here we have two core problems with security:

  1. Security changes daily – it’s hard to keep up
  2. It’s scary when you are new at this

Let’s start by addressing the second issue. Security is a scary topic, but let’s breaks it down into its core components.

  1. Security is about keeping data away from those who shouldn’t see it
  2. Security is about keeping data available for those who need to see it

At its core, security is simple. It starts getting tricky when you jump into the semantics of how to implement the core. So let’s address this too.

A properly working system will do what you intended it to do at a systematic level: calculate numbers, view customer information, launch a missile, etc. This is a fundamental tenant of application development. Security is about understanding the unintended consequences of what a user can do with that system.

These consequences are of the like:

  • SQL Injection
  • Cross Site Scripting attacks
  • Cross Site Forgery attacks
  • Buffer overflow attacks
  • Breaking encryption schemes
  • Session hijacking
  • etc.

Once you understand that these types of attacks can exist, everything is just semantics from this point on. These semantics are along the line of figuring out best practices for system designs, and that’s really just a matter of studying.

Security is about understanding that anything is possible. Once you understand attacks can happen, you learn how they can happen. Then you learn how to prevent them from happening. To use a phrase I really hate using, security is about thinking outside the box.

Most developers do the least amount of work possible to build an application. I am terribly guilty of this. In doing so however, there is a very high likelihood that I didn’t consider what else can be done with the same code. Making this consideration is (again, lame phrase) thinking outside the box.

It is in following this consideration that I can develop a secure system.

So… policies?

At the end of the day however, I am a lazy developer.  I will still do as little work as possible to get the system working, and frankly, this is not conducive to creating a secure system.

The only way to really make this work is to implement security policies that force certain considerations to be made.  Each system is different, and each organization is different.  There is no single policy that will cover the scope of all systems for all organizations, but a policy is simple. 

A policy is a rule that must be followed, and in this case, we are talking about a development rule.  This can include requiring certain types of tests while developing, or following a specific development model like the Security Development Lifecycle.  It is with these policies that we can govern the creation of secure systems.

Policies create an organization-level standard.  Standards are the backbone of security.

These standards fall under the category of semantics, mentioned earlier.  Given that, I propose an idea for learning security.

  • Understand the core ideology of security – mentioned above
  • Understand that policies drive security
  • Jump head first into the semantics starting with security models

The downside is that you will never understand everything there is to know about security.  No one will.

Perhaps its not that flawed of an idea.

Resources for Students who Hate School

I hated school.  Technically, I’m still enrolled in college.  Bachelors of Business Management.  Blech.  I figured at least with business, I would learn something useful later in life.  I chose against Comp. Sci. for a few reasons.  One being that I know a couple PhD’s that know nothing about building applications in the real world.

In Comp. Sci., you learn how to build data structures, and how to make Mandelbrot Set’s process faster.  In business, you learn why people buy stuff.  Or more appropriately, you learn how to get people to buy your stuff.

Seeing as I learned (taught myself?) about things like linked-lists and pointers while in grade 10-ish, and wrote/re-wrote/re-re-wrote Mandelbrot Set builders as a final project in grade 11, I think I can safely say I would be bored as all hell in University.  Not to mention all the theory.  Comp. Sci. is all about theory.  Maybe 10% is actually coding.  F-that.

Business is inherently hands-on.

I like hands-on.  It’s tangible.

The only problem I had was finding resources.  My programming teachers were pretty cool, and were always willing to help me on algorithms that confused me, as well as extra-curricular programs when something just wasn’t jiving.  But I had cool teachers.  Not everyone is as lucky as I was.  And with the teachers, they weren’t thinking in C# or ASP.NET everyday like I tended to do.  Trying to ask them why something trivial like

<asp:TextBox ID="txtUsername">

didn’t compile was kinda painful.  I usually got a response along the lines of “what’s the colon for?”.  I always felt funny trying to explain the quasi-xml structure of ASP.NET to teachers.  This left me in a lame position of needing to find help.  Forums are great, but separating the wheat from the chaff is a waste of time.  Enter stackoverflow.com (4 years late, mind you) and you get answers quickly.  I like it.  I use it all the time.  I’d like to think that those who are willing to look for resources will find the site fairly easily.  However, there is another site out there that not too many people know about.  It’s the Microsoft Student Experience site.  Yeah yeah, brain wash them early.  I drank the kool-aid early.

Part of the website is dedicated to the DreamSpark program.  Free, fully-licensed Microsoft products.  Nuff said.

image

The other half of the site is dedicated to students.  Good thing, given the name.  Not just students studying software development either.  All students.  It provides tangible resources for students.  Stories, tutorials, and templates look to be the main content.  It’s all surprisingly good stuff too.  It ranges from school studies to general life, to post-school life.

image 

These resources may help those students who are struggling with school – at any level.  There are students out there with lots of potential.  Let’s not see it go to waste.

What Makes us Want to Program? Part 4

In my previous post, I started talking about using Microsoft technologies over PHP and open source technologies.  There were a couple reasons why I chose to make the move.  First, from a development perspective, everything was object oriented.  PHP was just getting started with OOP at the time, and it wasn’t all that friendly.  Second, development time was generally cut in at least half, because of the built in controls of ASP.NET.  Third, the end result was a more rich application experience for the same reason.  The final reason comes down to the data aspect.

Pulling data from a database in PHP wasn’t easy to do.  The built in support was for MySQL, with very little, if next to nothing for SQL Server.  In a lot of cases that isn’t always a bad thing.  MySQL is free.  You can’t argue with that.  however, MySQL wasn’t what you would call ACID compliant.  Defined, MySQL did not have the characteristics of being Atomic, Consistent, Isolated, and Durable.  Essentially, when data goes missing, there is nothing you can do about it.  SQL Server on the other hand is very ACID compliant.  This is something you want.  Period.

Once .NET 2.0 was released, a whole new paradigm came into play for data in a web application.  It was easy to access!  No more, or at least next to very little boiler plate coding was necessary for data access now.  Talk about a selling point.  Especially when the developer in question is 16 going on 17.

Now that I didn’t need to worry about data access code, I could start working on figuring out SQL.  At the time t-SQL scared the crap out of me.  My brain just couldn’t work around datasets.  The idea of working with multiple pieces of data at once was foreign.  I understood single valued iterations.  A for loop made sense to me.  SELECTs and JOINs confused me.  Mind you, I didn’t start Statistics in math until the following year.  Did SQL help with statistics, or did statistics help me finally figure out SQL?  It’s a chicken and the egg paradox.

So here I am, 17 years old, understanding multiple languages, building dozens of applications, and attending developer conferences all the while managing my education in High School.  Sweet.  I have 3 years until the next release of Visual Studio comes out.  It was here that I figured I should probably start paying more attention in school.  It’s not so much that I wasn’t paying attention, it’s just that I didn’t care enough.  I put in just enough effort to skate through classes with a passing mark.  It was also at this point in time that I made an interesting supposition.

Experts tend to agree that people who are programming geniuses are also good at math and critical thinking or reasoning.  Not one or the other, but both.  Now I’m not saying I’m a programming genius, but I suck at math.  It was just never in the cards.  But, according to all those High School exams and the psychological profiling they gather from them, my Critical Thinking and Reasoning skills are excellent.  Top 10% in Canada according to the exam results.  My math skills sit around top 20-30% depending on the type.

Neurologists place this type of thinking in the left hemisphere of the brain.  The left brain is associated with verbal, logical, and analytical thinking. It excels in naming and categorizing things, symbolic abstraction, speech, reading, writing, arithmetic.  Those who live in the left brain are very linear.  Perfect for a software developer.

The supposition I made had more to do with the Pre-Frontal Cortex of the brain.  It does a lot of work, some of which is planning complex cognitive behaviors.  Behaviors like making a list, calculating numbers, abstracting thoughts, etc.  It plans out the processes our brains use to get things done.  This is true for both sides of the brain.  So, suppose you are left brain-oriented.  You are predisposed to be good at development.  Now, suppose your Pre-Frontal Cortex is very well developed, more so than the average person.  It could be reasoned that part of being a programming genius is having a well developed Pre-Frontal Cortex.

So why does this make us want to program?  Find out in Part 5.

What Makes us Want to Program? Part 1

When I saw this comic a couple weeks ago, it hit a chord just right with me.

Except of course it was PHP, and grade 9.  The funny thing was, I started writing programs way back when I was in grade 5.  I tried to start learning development when I was in grade 3.  Let me tell you, there are certain subtleties to programming that don’t quite become apparent to a 9 year old.

10 PRINT “Steve is Awesome!”
20 GOTO 10

While QBasic was fun to play with, I gave up on that when I found a book on Visual Basic in Grade 5.  I vaguely remember it being Visual Basic 5 too.  I could be wrong.  It was a little more than 10 years ago – you do the math.  The problem I found with VB was that it didn’t feel all that intuitive from a language perspective to me.  I could never find it to flow properly.  But at the time, that’s all I had to go on.  So I gave up on development for a while and tried my hand at HTML.  Once again, certain things just aren’t apparent at certain ages.  When I first tried HTML, I started in notepad.  Shortly thereafter I ended in notepad.  Maybe sports would be more fun?  Nah… Enter FrontPage a few months later.

After finally getting the hang of FrontPage, I built some amazing (read: ugly) sites.  All-in-all they weren’t bad for an 11 year old.

Once middle school rolled around, I tried my hand at the other sciences and found out I really enjoyed biology.  Being the semi-OCD-like person I am, I put all my attention into biology and medicine, with a curiosity for chemistry.  I knew way too much for my own good.

Now I have to mention that all of this is taking place in beautiful Southern California.  I was born and raised there for 14 years.  At the end of Grade 8, my parents decided to move to Canada.  Don’t ask - long story.  And at that time, I was still into the life sciences.  In my next post, I’ll continue on with my story.