Questions on TroopMaster DotNet Security

[Zachary Heaton-2]

All,

I am an ASM with a Troop that is considering purchasing a TroopMaster  
DotNet license to supplement our existing Troopmaster license.  I'm  
concerned about the security implications of regularly transmitting  
Troop personal data across the Internet, and have reviewed the  
TroopMaster DotNet literature and FAQs to determine what steps  
TroopMaster takes to secure personal data.  Unfortunately, what I've  
read so far has not been fully enlightening.  Can anyone, either a  
savvy customer or a TroopMaster employee, answer some of the following  
questions:

1.) Does DotNet connect to the FTP server used to store the data file  
using standard (unencrypted) FTP, or does it use SFTP or FTPS  
(encrypted) connections to secure the FTP login information?  If  
standard FTP is used, then sniffing the FTP passwords from network  
traffic would be trivial for an attacker, and the entire security  
scheme hinges on the strength of the data file encryption.

2.) The TroopMaster website states that data files can be encrypted  
using 256-bit AES encryption.  However, TroopMaster also provides a  
password recovery service <http://www.troopmaster.com/password/> which  
can recover the data encryption password.  This implies either the  
existence of a global "unlock" password, or a key generation algorithm  
which can generate "unlock" passwords from TroopMaster license  
information.  Since having this global password or algorithm would  
enable an attacker to unlock any TroopMaster data file anywhere, how  
is this global password secured?  Is the number of TroopMaster  
employees with access to this key limited?  If a key generation  
algorithm has been used, has the algorithm design been audited by a  
recognized cryptographic expert?

3.) The DotNet website has this to say on the advantages of using the  
TroopMaster FTP site:

> For all of our versions of DotNet, security is further enhanced if  
> you rent your FTP site directly from Troopmaster Software because we  
> don't release the actual location of the server to anyone. The site  
> can only be used by and for DotNet.

This statement seems nonsensical - packet sniffing of the data  
transfer from a TroopMaster client would trivially reveal the IP  
address of the server, which in turn would probably reveal the  
physical location (or at least the datacenter) of the server  
hardware.  What location is being protected here, how, and why?  If  
the server is properly secured, how does hiding the server location  
improve the security of the data?

4.) The DotNet website says that it is possible to block sensitive  
data fields (SSNs, driver license numbers) from certain users.  Are  
these restrictions cryptographically enforced, or are they only  
enforced by TroopMaster permissions-checking logic?  If the latter,  
has the possibility of unauthorized users recovering sensitive data  
either by reverse-engineering the file format or by examining program  
state using a debugger been considered and addressed?

Thanks in advance for any light you can shed on these issues - I'm  
intrigued by the capabilities that DotNet provides, but I want to make  
sure that we're appropriately protecting Scout personal information.

Regards,
Zach Heaton

[NDXhound]

I have used DotNet for about a year and have been forced to learn more about its inner workings than I wanted. I understand your concerns. Given the level of security you are suggesting is needed, I don't think DotNet will address each point to your satisfaction.

I am curious though...when you email your database around do you use certificate-base encryption to ensure security? If you use USB keys to move the database around, how do you guard against lost keys. What about people who use work computers (domain admins know much)? What about lost/reclaimed laptops? Are your TM users bonded?

Security is always a concern when working with sensitive data. There is always room for improvement. In the end it is a risk-reward decision balancing the sensitivity of the data with the barriers imposed by security measures.

As an alternative you can eliminate photos, SSN's and drivers licence numbers (medical info too) from TM leaving only data that could be discovered via Google...or even a trip to Council office requesting a Troop roster. This will retain 90% of TM's functionality.

Peter

To: tmtug@...
From: zheaton@...
Date: Mon, 25 May 2009 22:38:44 -0400
Subject: [TMTUG] Questions on TroopMaster DotNet Security




















   
           
           


     
      All,



I am an ASM with a Troop that is considering purchasing a TroopMaster  

DotNet license to supplement our existing Troopmaster license.  I'm  

concerned about the security implications of regularly transmitting  

Troop personal data across the Internet, and have reviewed the  

TroopMaster DotNet literature and FAQs to determine what steps  

TroopMaster takes to secure personal data.  Unfortunately, what I've  

read so far has not been fully enlightening.  Can anyone, either a  

savvy customer or a TroopMaster employee, answer some of the following  

questions:



1.) Does DotNet connect to the FTP server used to store the data file  

using standard (unencrypted) FTP, or does it use SFTP or FTPS  

(encrypted) connections to secure the FTP login information?  If  

standard FTP is used, then sniffing the FTP passwords from network  

traffic would be trivial for an attacker, and the entire security  

scheme hinges on the strength of the data file encryption.



2.) The TroopMaster website states that data files can be encrypted  

using 256-bit AES encryption.  However, TroopMaster also provides a  

password recovery service <http://www.troopmaster.com/password/> which  

can recover the data encryption password.  This implies either the  

existence of a global "unlock" password, or a key generation algorithm  

which can generate "unlock" passwords from TroopMaster license  

information.  Since having this global password or algorithm would  

enable an attacker to unlock any TroopMaster data file anywhere, how  

is this global password secured?  Is the number of TroopMaster  

employees with access to this key limited?  If a key generation  

algorithm has been used, has the algorithm design been audited by a  

recognized cryptographic expert?



3.) The DotNet website has this to say on the advantages of using the  

TroopMaster FTP site:



> For all of our versions of DotNet, security is further enhanced if  

> you rent your FTP site directly from Troopmaster Software because we  

> don't release the actual location of the server to anyone. The site  

> can only be used by and for DotNet.



This statement seems nonsensical - packet sniffing of the data  

transfer from a TroopMaster client would trivially reveal the IP  

address of the server, which in turn would probably reveal the  

physical location (or at least the datacenter) of the server  

hardware.  What location is being protected here, how, and why?  If  

the server is properly secured, how does hiding the server location  

improve the security of the data?



4.) The DotNet website says that it is possible to block sensitive  

data fields (SSNs, driver license numbers) from certain users.  Are  

these restrictions cryptographically enforced, or are they only  

enforced by TroopMaster permissions-checking logic?  If the latter,  

has the possibility of unauthorized users recovering sensitive data  

either by reverse-engineering the file format or by examining program  

state using a debugger been considered and addressed?



Thanks in advance for any light you can shed on these issues - I'm  

intrigued by the capabilities that DotNet provides, but I want to make  

sure that we're appropriately protecting Scout personal information.



Regards,

Zach Heaton



 

     

   
   
       
       
       
       


       


       
       

[Charles McCutcheon]

> DotNet license to supplement our existing Troopmaster license.  I'm  
> concerned about the security implications of regularly transmitting  
> Troop personal data across the Internet

I'll be interested in replies you get.

TroopMaster has a "data encryption password" which is set per user and I assume is used for sftp/ssl/tls transmissions.  My memory is that its advertized that you can just change this password to disable people when they leave the troop, and not change the other passwords.

We do NOT keep social security numbers in the database.  Only needed to do for one time background checks on adults, I've seen no uses for them for Scouts, and refused to give them for my boys.  But the field is there...

[Matt Price]

 > DotNet license to supplement our existing Troopmaster license. I'm
 > concerned about the security implications of regularly transmitting
 > Troop personal data across the Internet

Historically, most of the data that gets lifted is not that being
transmitted electronically.  It is the information in the trash can or
in other peoples hands that commonly become an issue of pilfering.

 > TroopMaster has a "data encryption password" which is set per user
 > and I assume is used for sftp/ssl/tls transmissions. My
 > memory is that its advertized that you can just change this password
 > to disable people when they leave the troop, and not
 > change the other passwords.

Unless my memory fails me, all information is transmitted via dot net to
secure servers, which is then translated and replicated with Scoutnet
servers.

 > We do NOT keep social security numbers in the database. Only needed
 > to do for one time background checks on adults, I've seen no uses for
them for
 > Scouts, and refused to give them for my boys. But the field is there...

Social Security numbers for the sake of the unit are not needed.  In
fact, Social Security numbers for national are really not needed because
100% of all criminal background checks are done by name and birthdate.

[J. Scott Moncrief]

On Tue, May 26, 2009 at 6:45 PM, charlie_mccutcheon <
cdmccutcheon@...> wrote:

>   <snip>
>
> We do NOT keep social security numbers in the database. Only needed to do
> for one time background checks on adults, I've seen no uses for them for
> Scouts, and refused to give them for my boys. But the field is there...
> </snip>
> .
>  
>

I follow the same principles.  Have seen no reason to have the SSN's in PM.
 As best I could tell on the Re-Chartering, the match-up used the BSA ID #.
 I was only prompted for SSN in the Re-Charter packet for adults that were
not already in the Charter.
DotNet and PM seems to have several layers of protection:
DotNet access protection
Data Encryption
Database Access protection

-Scott
--
J. Scott Moncrief - Sparta, NC
Pack 299 Advancement Chair

[Zachary Heaton-2]

On 26 May 2009, at 18:58, J. Scott Moncrief wrote:

> <snip>
>
> DotNet and PM seems to have several layers of protection:
> DotNet access protection
> Data Encryption
> Database Access protection
>
> -Scott

Scott,

Yes, but as best as I can tell, only a few of those layers are really  
substantial.

  - DotNet access protection.  If encrypted FTP is used to exchange  
passwords, then this is reasonably secure.  If standard unencrypted  
FTP is used, then a determined attacker will go through this without  
any trouble at all.

  - Data Encryption.  As best as I can tell, this is the "bet the  
farm" layer.  If the data encryption holds, then nothing else  
matters.  If the data encryption doesn't hold, then game over,  
attacker wins.  This is why I'm particularly concerned about  
TroopMaster password recovery - that looks to me like the greatest  
weakness in the encryption layer.

  - Database access protection.  I'm not putting a lot of trust in  
this layer, because anyone who's gotten this far has a full,  
unencrypted copy of the database on their hard disk.  There are  
several ways to attack this - patching the TroopMaster executable to  
bypass permissions checks, reverse-engineering the database format,  
and possibly dumping the database contents out of RAM once they're  
loaded.  Worst of all, this is a crack-once-run-anywhere attack - once  
you have a single patched copy of TroopMaster or once you've reverse  
engineered the file format, you can use that attack for any  
TroopMaster data file.  I trust the access protection to keep Scout  
parents honest, but it's a speed bump for a serious attacker.

Yours in Scouting,
Zach Heaton

[Zachary Heaton-2]

On 26 May 2009, at 18:53, Matt Price wrote:

>> DotNet license to supplement our existing Troopmaster license. I'm
>> concerned about the security implications of regularly transmitting
>> Troop personal data across the Internet
>
> Historically, most of the data that gets lifted is not that being
> transmitted electronically.  It is the information in the trash can or
> in other peoples hands that commonly become an issue of pilfering.

Historically, yes.  However, this trend is changing.  If you take a  
look at the Verizon 2008 data breach report (a fascinating read), over  
the past four years physical access was only an attack pathway in 21%  
of data breaches.  The big winners are remote access and control  
software (42%), web applications (34%), trailed by internet-facing  
systems (24%).

Of further interest is Verizon's breakdown of information channels  
which were attacked - online data was involved in 93% of the breaches  
they studied, offline data in 7%, and end-user devices in 7%.  This  
correlates with intuition suggesting that repositories with more data  
are more likely to be attacked.

<http://www.verizonbusiness.com/resources/security/databreachreport.pdf>

Applying this thinking to TroopMaster, this suggests that the DotNet  
storage servers are the "mother load" and the most likely attack  
target, since they would give the best return for an attacker's  
investment.

>> TroopMaster has a "data encryption password" which is set per user
>> and I assume is used for sftp/ssl/tls transmissions. My
>> memory is that its advertized that you can just change this password
>> to disable people when they leave the troop, and not
>> change the other passwords.
>
> Unless my memory fails me, all information is transmitted via dot  
> net to
> secure servers, which is then translated and replicated with Scoutnet
> servers.

It's the definition of "secure servers" that has me worried - if the  
communications with the servers are not encrypted, then the servers  
aren't all that secure.  Can anyone with DotNet and a copy of  
WireShark (or detailed firewall logs) confirm whether or not the  
DotNet traffic is encrypted? <http://www.wireshark.org/>

Additionally, vulnerabilities in the FTP servers could expose the  
service to attack - e.g, the recent ProFTPD SQL injection  
vulnerability.  <http://isc.sans.org/diary.html?storyid=5845>

I honestly wouldn't worry about the server security as much if there  
weren't phrases in the TroopMaster marketing materials about "we don't  
release the actual location of the server to anyone" If they're  
talking about hiding the server IP address, then this is a)  
nonsensical and b) displays a fundamental lack of understanding of how  
the Internet works.  This does not give me a great deal of confidence  
in the security of TroopMaster's server configuration, and I really  
hope that the person who wrote that ad copy is not the server admin.

As for the ScoutNet servers, I hadn't seen that one before - if the  
data is synchronized with ScoutNet automatically, then that's another  
attack surface to secure.

>> We do NOT keep social security numbers in the database. Only needed
>> to do for one time background checks on adults, I've seen no uses for
> them for
>> Scouts, and refused to give them for my boys. But the field is  
>> there...
>
> Social Security numbers for the sake of the unit are not needed.  In
> fact, Social Security numbers for national are really not needed  
> because
> 100% of all criminal background checks are done by name and birthdate.

Agreed wholeheartedly - I'm not certain why National puts them on the  
adult application as "required," but I have not desire to store them  
myself.

Yours in Scouting,
Zach Heaton

[Zachary Heaton-2]

On 26 May 2009, at 9:59, NDXhound wrote:

> I have used DotNet for about a year and have been forced to learn  
> more about its inner workings than I wanted. I understand your  
> concerns. Given the level of security you are suggesting is needed,  
> I don't think DotNet will address each point to your satisfaction.

Peter,

Thanks for the reply.  I don't necessarily need DotNet to address each  
point, I'm just trying to understand the security approach TroopMaster  
Software is using.  My area of greatest concern is the password  
recovery mechanism.  Most of my other questions (FTP vs SFTP, server  
location, etc.) aren't that important if the data file is securely  
encrypted - if the data file is not securely encrypted, then all of  
those other concerns become very important.

> I am curious though...when you email your database around do you use  
> certificate-base encryption to ensure security?

Partially.  Several of the adult leaders (myself included) use  
encryption certificates, and one of my medium-term goals is rolling  
out a PKI infrastructure with associated Troop e-mail addresses for  
all of the adults in the Troop.

> If you use USB keys to move the database around, how do you guard  
> against lost keys.

This is a non-issue *if* the data file itself is encrypted.  256-bit  
AES with a strong password should be immune to any reasonable degree  
of cryptographic attack - the wildcard is the password recovery  
mechanism/backdoor which TroopMaster contains.  If that can be broken  
more cheaply than the data encryption password, then the 256-bit AES  
encryption isn't adding anything to the security.

> What about people who use work computers (domain admins know much)?  
> What about lost/reclaimed laptops?

Again, neither of these should be huge issues if the data file is  
encrypted. [1]

> Are your TM users bonded?

No, but given our youth protection policy (we're chartered to a  
Catholic parish) they are all fingerprinted and subject to criminal  
background checks, in addition to the BSA background checks.

> Security is always a concern when working with sensitive data. There  
> is always room for improvement. In the end it is a risk-reward  
> decision balancing the sensitivity of the data with the barriers  
> imposed by security measures.

Agreed entirely, and that's why I'm not too worried about elaborate  
targeted attacks against our troop computers or about bonding local  
TroopMaster users.  We don't store personal information on enough  
people to make a complicated technical or social attack worthwhile,  
and I'm (perhaps optimistically) assuming we don't have much of an  
insider threat from Scout parents.  The two threats that have me  
concerned are:

1.) An attack against the DotNet FTP servers to mass-download  
TroopMaster databases stored there.  If the FTP passwords are sent  
unencrypted, then this is relatively straightforward to do.

2.) An attack against the password recovery function in TroopMaster  
which allows the unlocking of all TroopMaster file encryption.

#1 is bad, #2 is very bad, and a combination of #1 and #2 would be  
almost unspeakably bad.  At this point, the rewards of an attack also  
start to become reasonable - instead of getting the personal  
information from one Troop, an attacker could get the personal  
information from hundreds of troops.

> As an alternative you can eliminate photos, SSN's and drivers  
> licence numbers (medical info too) from TM leaving only data that  
> could be discovered via Google...or even a trip to Council office  
> requesting a Troop roster. This will retain 90% of TM's functionality.

SSNs I'm definitely willing to sacrifice - I'm not certain why that's  
marked as a "required" field on the BSA adult application, and frankly  
I'm not comfortable storing them.  Photos are reasonably easy to  
sacrifice, but driver license numbers are painful to lose, given that  
they're needed for preparing tour permits.

> Peter

Yours in Scouting,
Zach Heaton

[1] Aside:  If the encryption is robust, the only two methods of  
attack that come to mind offhand are attacking the encryption password  
while it's being entered (e.g., a keystroke logger) or attacking the  
encryption password/file contents when they're loaded into RAM  
(similar to the Blu-Ray copy protection attacks).  Those sorts of  
attacks are a concern, but they're difficult to mitigate for any  
software, and they assume that the computer reading the TroopMaster  
file has already been compromised and is nontrustworthy.  For this  
reason, I'm not too worried about those sort of attacks.

[Mark Wilbur-2]

> Security is always a concern when working with sensitive data.
 
I recently discovered a problem that was not an issue for "us" but might
be
if you had a needed to suddenly lock someone out.
 
We had an adult pass away and I was not sure what would happen to his
computer
so I locked him out of the database.
 
Well while I was helping the family with the funeral, we needed to
access
his database for his own camping records. At first I thought I could not
get to them from
his computer. But then it dawned on me that all I had to do was hold
down the
SHIFT key when starting his program and I could continue using the "off
line" copy.
 
It worked like a champ!
 
Not sure if there is an easy solution here if you needed to ban a user.
 
 

   /\mmm/\    Mark Wilbur - Scoutmaster - Eagle Scout - Vigil:Allogagaw
    (o) (o)  Owl NC516 - Shawnee Lodge 51 - St. Louis, Mo. - Ham:N0UII
      \ v /         <http://www.troop374.org/> http://www.troop374.org
-   <mailto:allogagaw@...> allogagaw[at]gmail.com
>>-+++-->  

 

 

[Scully0007]

When I first suggested we use TroopMaster some of the guys on our Committee brought up security. I have to admit I don't know much about it but I figure it's a lot more secure than the way we used to do it. Each trip leader would have their own Excel sheets on their own computers with drivers license numbers and the like. Of course others had their own Excel sheets and other files for their own reasons. No way to "lock-out" someone who was no longer registered, etc. So I think that makes TroopMaster much more secure than the alternative.

Kathy

Troop 746
Fullerton, MD

[Charles McCutcheon]

Unless I've missed a message; no one from TroopMaster has replied about their security?

I'd feel better if they talked about what's done.  Strong algorithms should not be breakable; as long as the encryption keys are kept secure.

Charlie

[Tim Musson-2]

Hey Charlie,

Monday, June 1, 2009, 8:36:06 AM, you wrote:

> Unless I've missed a message; no one from TroopMaster has replied
> about their security?

> I'd feel better if they talked about what's done.

I am not disagreeing with you, but in the time I have been reading
this User Group, I don't think I have seen a single message from
TroopMaster. If you want an answer from TM, you would have to ask TM,
not the members of the _User_ Group...

I believe TM reads the messages in this group, but I have never seen
anything indicating that TM sponsors or runs it...

--
Tim

[Greg Marr]

At 08:52 AM 6/1/2009, Tim Musson wrote:
>I am not disagreeing with you, but in the time I have been reading
>this User Group, I don't think I have seen a single message from
>TroopMaster.

They do respond here occasionally.  It's usually Sam.

>I believe TM reads the messages in this group, but I have never seen
>anything indicating that TM sponsors or runs it...

That is correct, they do not.

--
Greg Marr
gregm@...

[frasert]

This is a user forum.  Troop master monitors it casually but if you news
a specific question answered contact them via the TM support website.
They will definitely answer that quickly.  You could share their answer
here.
Tim
--------------------------
Sent using BlackBerry


-----Original Message-----
From: TMTUG@... <TMTUG@...>
To: TMTUG@... <TMTUG@...>
Sent: Mon Jun 01 08:36:06 2009
Subject: [TMTUG] Re: Questions on TroopMaster DotNet Security

Unless I've missed a message; no one from TroopMaster has replied about
their security?

I'd feel better if they talked about what's done.  Strong algorithms
should not be breakable; as long as the encryption keys are kept secure.

Charlie




------------------------------------

Yahoo! Groups Links

[J. Scott Moncrief]

On Mon, Jun 1, 2009 at 8:52 AM, Tim Musson <tim@...> wrote:

>   <snip>
> I am not disagreeing with you, but in the time I have been reading
> this User Group, I don't think I have seen a single message from
> TroopMaster. If you want an answer from TM, you would have to ask TM,
> not the members of the _User_ Group...
>
> I believe TM reads the messages in this group, but I have never seen
> anything indicating that TM sponsors or runs it...
>
> --
> Tim
>
>
>

More importantly, does anyone recall a discussion  of a security breach
here?

--
J. Scott Moncrief - Sparta, NC