Application Security

[Guest]

Can someone shed some light or point me to the right direction regarding
'Application Security'.

I was just asked by my manager to write an article about the topic above. I
work for a financial institution with about 50 developers and we need to
secure our sources from prying eyes and/or malicious intentions. We mainly
develop web applications, both internally and externally, with some console &
Window apps strewn here and there.

I'd like to know what we, the developers, have to keep in mind or take into
considerations during developing to keep our sources secure. What can we do
with our IIS settings to close any gaps.

Any help would be greatly appreciated.

 

[Mick Walker]

Can someone shed some light or point me to the right direction regarding
'Application Security'.

I was just asked by my manager to write an article about the topic above. I
work for a financial institution with about 50 developers and we need to
secure our sources from prying eyes and/or malicious intentions. We mainly
develop web applications, both internally and externally, with some console &
Window apps strewn here and there.

I'd like to know what we, the developers, have to keep in mind or take into
considerations during developing to keep our sources secure. What can we do
with our IIS settings to close any gaps.

Any help would be greatly appreciated.

(Sorry I cant resist)

I hope your not the financial institution which I use if you don't know
this already

 

[Peter Duniho]

[...]
I'd like to know what we, the developers, have to keep in mind or take into
considerations during developing to keep our sources secure. What can we do
with our IIS settings to close any gaps.

Any help would be greatly appreciated.

Define "sources". Do you mean the actual source code for your software?

If so, then the simple answer is:

1) Any software that runs on the client's computer is not securable. If
you are a target for an attack, you must assume that the client software
is 100% compromised. Because if there's any incentive for someone to
compromise it, they can and they will. This applies to any reverse
engineering, whether it's recovering your implementation, or simply
whatever application-level network protocol, file format, etc. you may
be using.

2) Any software that runs on the server side is secured the same way you
would secure any server-side stuff. Keep hackers out of your servers,
and they can't get at your server side software, source code or otherwise.

AFAIK, there's no "magic bullet" IIS setting that just secures things.
Security is a multi-layered thing, and you have to be careful to not
compromise it at every step of the way.

The actual _source_ code you can keep secure simply by not putting it on
a network that is reachable from the Internet, directly or indirectly.
But any software can be reverse-compiled, and .NET more so, even if you
use one of the available "obfuscation" tools. So, just because your
source files aren't directly accessible, that doesn't mean a hacker
can't inspect your code.

On the bright side, basic network security is reasonably simple and
probably already well-understood by you, and/or whoever is managing your
servers (one hopes ). And application security -- that is, attack
vectors that reside in the form of bugs in your server-side software --
tends to be much improved in .NET applications, because .NET has taken
care of a great deal of the usual kinds of errors that you can introduce.

Which is not to say that you are immune. You still need to be careful
about handling _any_ data that comes in over the network. But a lot of
the potential errors you might make are simply prevented by .NET.

As a general recommendation, I really like the book "Writing Secure
Code" by Michael Howard and David LeBlanc (from Microsoft Press).

Pete

 

[Guest]

Thanks a million Peter.

Your response did shed some light. I just have to dive into the .NET
security issues. And thanks for recommending the book...

[...]
I'd like to know what we, the developers, have to keep in mind or take into
considerations during developing to keep our sources secure. What can we do
with our IIS settings to close any gaps.

Any help would be greatly appreciated.

Define "sources". Do you mean the actual source code for your software?

If so, then the simple answer is:

1) Any software that runs on the client's computer is not securable. If
you are a target for an attack, you must assume that the client software
is 100% compromised. Because if there's any incentive for someone to
compromise it, they can and they will. This applies to any reverse
engineering, whether it's recovering your implementation, or simply
whatever application-level network protocol, file format, etc. you may
be using.

2) Any software that runs on the server side is secured the same way you
would secure any server-side stuff. Keep hackers out of your servers,
and they can't get at your server side software, source code or otherwise.

AFAIK, there's no "magic bullet" IIS setting that just secures things.
Security is a multi-layered thing, and you have to be careful to not
compromise it at every step of the way.

The actual _source_ code you can keep secure simply by not putting it on
a network that is reachable from the Internet, directly or indirectly.
But any software can be reverse-compiled, and .NET more so, even if you
use one of the available "obfuscation" tools. So, just because your
source files aren't directly accessible, that doesn't mean a hacker
can't inspect your code.

On the bright side, basic network security is reasonably simple and
probably already well-understood by you, and/or whoever is managing your
servers (one hopes ). And application security -- that is, attack
vectors that reside in the form of bugs in your server-side software --
tends to be much improved in .NET applications, because .NET has taken
care of a great deal of the usual kinds of errors that you can introduce.

Which is not to say that you are immune. You still need to be careful
about handling _any_ data that comes in over the network. But a lot of
the potential errors you might make are simply prevented by .NET.

As a general recommendation, I really like the book "Writing Secure
Code" by Michael Howard and David LeBlanc (from Microsoft Press).

Pete

 

[Rad [Visual C# MVP]]

[...]
I'd like to know what we, the developers, have to keep in mind or take into
considerations during developing to keep our sources secure. What can we do
with our IIS settings to close any gaps.

Any help would be greatly appreciated.

Define "sources". Do you mean the actual source code for your software?

If so, then the simple answer is:

1) Any software that runs on the client's computer is not securable. If
you are a target for an attack, you must assume that the client software
is 100% compromised. Because if there's any incentive for someone to
compromise it, they can and they will. This applies to any reverse
engineering, whether it's recovering your implementation, or simply
whatever application-level network protocol, file format, etc. you may
be using.

2) Any software that runs on the server side is secured the same way you
would secure any server-side stuff. Keep hackers out of your servers,
and they can't get at your server side software, source code or otherwise.

AFAIK, there's no "magic bullet" IIS setting that just secures things.
Security is a multi-layered thing, and you have to be careful to not
compromise it at every step of the way.

The actual _source_ code you can keep secure simply by not putting it on
a network that is reachable from the Internet, directly or indirectly.
But any software can be reverse-compiled, and .NET more so, even if you
use one of the available "obfuscation" tools. So, just because your
source files aren't directly accessible, that doesn't mean a hacker
can't inspect your code.

On the bright side, basic network security is reasonably simple and
probably already well-understood by you, and/or whoever is managing your
servers (one hopes ). And application security -- that is, attack
vectors that reside in the form of bugs in your server-side software --
tends to be much improved in .NET applications, because .NET has taken
care of a great deal of the usual kinds of errors that you can introduce.

Which is not to say that you are immune. You still need to be careful
about handling _any_ data that comes in over the network. But a lot of
the potential errors you might make are simply prevented by .NET.

As a general recommendation, I really like the book "Writing Secure
Code" by Michael Howard and David LeBlanc (from Microsoft Press).

Pete

I can also vouch for that book. Tremendous help!