Application security auditing and logging

Auditing is one of the main pillars of security policies. The question is how to do it wisely

The infrastructure can log almost everything. For example access to files, registry keys databases etc. The problem is that the infrastructure has no knowledge about the application use cases. It means that the context for these logs is missing.

Let us ask what is the purpose of auditing? The trivial reason is to collect information that will be useful in case of a problem, yet how do you know that there is a problem after all?

Auditing can help you identify that you are in an abnormal state and something is wrong.
To do that you have to be able to distinguish between normality and abnormality. The application knows its use cases. It knows their behavior patterns and so can identify that something is wrong. This is why only the application layer can perform smart security auditing.

Application logging and auditing is used to collect enough information to analyze the behavior of the application use cases and identify any abnormal situation, then the information collected with traditional logging is used to identify the problem and find the best action.

Enjoy

Manu

Http error 405 when calling STS

I wrote a simple example for demonstrating delegation with Windows Identity Framework (WIF).
I created a simple web site that used a simple custom STS for authentication. The web site called another web service to calculate a simple calculation (calculator).

The web site used passive federation using a simple asp.net STS. SOAP Web service in general can only use passive federation for authentication, so I created another WCF custom STS.

The idea was that the web application will obtain an act-as token from the active STS using the token it received from the client (using the passive STS) and then call the calculator web service.

When I run the code I got the "http error 405 method not allowed".

Http error 405 means that there is a mismatch between the http verb (e.g. Post, Get) between the call and the service. If the service waits for a http put and we send a http get request this is the error that will be triggered.

My problem was simple. I called the base address of the STS instead of the STS itself. I did that by specifying the base address of the STS in the issuer configuration. When I fixed the address to the real address of the STS the problem was solved.

 <customBinding>
   <binding name="CustomBinding_ICalc">
     <security authenticationMode="IssuedTokenForCertificate" 
           messageSecurityVersion="WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12BasicSecurityProfile10">
            <issuedTokenParameters keyType="SymmetricKey"
                                   tokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1">
              <issuer address="http://manu-newlap/WCFSTS/service.svc"
                      binding="ws2007HttpBinding"
                      bindingConfiguration="http://manu-newlap/WCFSTS">
              </issuer>
              <issuerMetadata address="http://manu-newlap/WCFSTS/mex" />
            </issuedTokenParameters>
          </security>
          <httpTransport/>
   </binding>
 </customBinding>

The call to the STS to obtain an Act-As token is implemented by sending a http post request that contains the bootstrap token received from the passive STS. The base address does not allow non Get requests so my Post request was rejected.

remember that STS is a simple WCF service. The same rules that applies in simple WCF applies here.

Hope this will help.

Manu

כלכלת ענן

Hi this post will be written in Hebrew (sorry for all English speakers)

כולנו שומעים על ענן מכל כיוון אפשרי. נשאלת השאלה למה?
מה עושה את הענן הזה לשם החם הבא? מה הסוד מאחורי המושג הזה?

הכול מתחיל ונגמר בכסף. הסיפור הוא כלכלי.

מחוק מור למדנו שכל שנתיים מערכות מכפילות את יכולתן הטכנולוגית השאלה שנשאלת מה קורה למחיר? בסביבה הטכנולוגית כיום הלקוח התרגל לא רק לקבל מערכות טובות יותר ככל שהזמן עובר, אלא גם לשלם פחות. זה מוזר מבחינה כלכלית – לקבל יותר אך לשלם פחות.

הכול טוב ויפה מצדו של הצרכן אבל נותן השירות או ספק התוכנה נמצא במצב מביך, הלקוח דורש דרישות הולכות וגדלות אך מצד שני הוא מוכן לשלם פחות. בימינו הצרכן דורש אמינות מושלמת זמינות מוחלטת, ביזור ועמידה בעומסים משתנים. ניתן כמובן לספק יכולות כאלו הבעיה רק שזה ממש יקר. והלקוח כאמור לא מוכן לשלם.

במצב כזה אין ברירה אלא לשנות משהו בסיסי כי במצב הנוכחי פשוט אי אפשר לספק את הדרישות במחירי השוק. פה מגיע הענן.

הענן הוא ההזדמנות של השוק לגדול מבחינה טכנולוגית ועדיין להישאר רלוונטי מבחינה כלכלית. זוהי הסיבה שכולם מדברים על הענן מפני שזו היא התשתית עליה תתבסס התעשייה בעתיד הקרוב.

הרעיון שעומד מאחורי הענן אינו חדש. תשתיות הן דבר יקר ובעל נצילות נמוכה. שיתוף תשתיות הוא פוטנציאל אדיר לחיסכון בכסף. המימוש המפורסם ביותר של הרעיון הזה מגיע מתשתיות החשמל. למי מאתנו יש תחנת כוח ביתית שמספקת את כל תצרוכת החשמל שלנו? לרובנו זו נראית שאלה מגוחכת. למה לי לבנות תשתית יקרה של גנרטורים שיספקו לי הרבה חשמל למזגנים בקיץ ולחימום בחורף ומעט חשמל באביב ובסתיו כשאני יכול בפשטות כה רבה לקנות חשמל בזול מחברת חשמל ולשלם בדיוק לפי הצריכה שלי?

האנלוגיה ברורה. למה לי להקים מרכז מחשוב יקר שיספק לי את הכוח הדרוש לשעות העומס ויעמוד בטל בשאר ימות השנה כשאני יכול בפשטות לקנות כוח מחשוב ואזורי אחסון בענן ולשלם בדיוק לפי צריכה?

כנראה עוד מספר שנים השאלה עם לעבוד בענן תראה טריוויאלית בדיוק כמו השאלה אם לרכוש חשמל מספק מרכזי. כיום אנו בתחילתו של עידן אבל הכיוון ברור והתעשייה כולה מתנהגת בהתאם. ספקי התקשורת (Telecoms) בונים לנו ערוצים ייעודיים לענן כדי להבטיח ביצועים בסביבה מבוזרת. ספקי הענן בונים מרכזי מחשוב (Data Centers) ענקיים ומשקיעים מיליארדים בפיתוח הטכנולוגיה אשר תאפשר לנו בקלות להשתמש בשירותי הענן שלהם. יצרני מערכות ההפעלה וה – Hypervisors בונים תשתיות תוכנה ייעודיות לבניית מרכזי מחשוב ענן (ראה Windows Server 8 כדוגמא). יצרני החומרה בונים רכיבים מיוחדים עבור שרתים בענן וספקי התוכנה מספקים את מרכולתם כ – Software as a Service.

בקיצור הענן הוא הדבר הבא כי הוא מספק את ההזדמנות הכלכלית שכל כך דרושה לתעשיית המידע.

Azure ServiceBus Topic using REST API – Part 4

In the three last post's we learned how to use Azure ServiceBus REST API to send and receive messages using Topics.

The difference between Queues and Topics is the fact that with topics different customers can receive different messages according message filtering which is deployed as filtering rules on the subscription. MSDN describe the following about topics and rules:

Topics extend the messaging features provided by Queues with the addition of Publish-Subscribe capabilities.
Each Subscription can define one or multiple Rule entities. Each Rule specifies a filter expression that is used to filter messages that pass through the subscription and a filter action that can modify message properties. In particular, the SqlFilterExpression class allows you to define a SQL92-like condition on message properties:

• OrderTotal > 5000 OR ClientPriority > 2
• ShipDestinationCountry = ‘USA’ AND ShipDestinationState = ‘WA’

Conversely, the SqlFilterAction class can be used to modify, add or remove properties, as the filter expression is true and the message selected, using a syntax similar to that used by the SET clause of an UPDATE SQL-command.

• SET AuditRequired = 1
• SET Priority = 'High', Severity = 1

Each matching rule generates a separate copy of the published message, so any subscription can potentially generate more copies of the same message, one for each matching rule.

Let us learn how to Add a rule and action using the REST API.

To add a rule to a subscription we need to provide a rule description. To do that I created a rule, action and filter description classes.

The rule description contains rule actions.

The rule description contains rule filters

Now we are ready to add a new rule using REST API

As you can see the first thing we do is delete the default rule that accepts all messages. Then we attach the serialization of our rule description to a PUT Http request we send to the URI of the new rule at:
https://{serviceNamespace}.servicebus.windows.net/{topicName}/subscriptions/{subscriptionName}/rules/{ruleName}

That is it. We have a new rule on our subscription.

With that I end the Series of post about using REST API of AppFabric Topics.

Enjoy

Manu

Azure ServiceBus Topic using REST API – Part 3

In the last two posts we showed how to use the Azure ServiceBus service bus REST API to send a message to a topic.
In this post we will see how to listen on a topic and receive a message.

There are two options:

1. Receive a message and delete it from the topic.

2. Receive the message but keep it locked on the queue until we decide to delete it (for example after message processing succeeded).

The following table describe the information that will be placed in the brokerProperties object 

To delete a lock or delete message (after the lock is deleted) I will use a general method for deleting service bus resources

That's all we received a message. On the next post we will learn how to create a rule for a subscription.

Enjoy

manu

Azure ServiceBus Topic using REST API – Part 2

In the last post I described why to use REST API when working with Azure service bus and demonstrated how to create a topic and subscription.

In this post we will actually send a message to the topic.

When sending a http request with a message to a topic we have to provide two special headers
1. Authorization header with the token we received from ACS
2.  BrokerProperties with Json serialization of metadata of metadata about our message.

To do that let us create a special class that will help us represent and serialize the metadata.

Now we know how to create a token (previous post) and represent metadata. so let us send a message

As you can see I put the receiver name in the "To" properties of the BrokerProperties object. This will allow us later to create a rule that filter the messages accordingly (e.g. To=receiver)

Also you can see that I propagated all of the message's properties. A propagated property is placed as a Http header and provide the ability to later filter messages according to its value by creating a relevant rule.
In production I assume that you will propagate only the properties you need !!!

The body message contains the DataContract Serialization of our data.
All we need to do is send the Http Request (using POST verb) to our topic at:
https://{namespace}.{appfabric.windows.net}/{topicname}//messages?timeout=60

Enjoy

Manu