[cssm] [EXTERNAL] Re: SACP: configuration of tranfer services

Wed Feb 17 11:01:43 UTC 2021

Hello

At the risk of wading in to a sensitive area, it seems to me that the 
expected advantage of a pass specific SICF over a permanent SICF is 
pass-specific credentials. If the credentials are accidentally exposed, 
there is a much smaller window in which they could be misused.
However, having even one pass hijacked could in the worst case lead to 
loss of a mission.

If I?m already wrong at this state, please correct me gently and ignore 
the rest?

This is wrong.
The credential are not part of the SICF.

The credential (user/password) are stored in the SLE provider repository.

The pass specific SICF concept introduces 3 weakness which can result in a 
bind failure or service degradation.
They are clearly weakness, as they cause problem to operational usage, not 
to someone willing to damage the service.
- Time range request => If you support times change, you get unbind
- Pass specific Sagr => If it does not match, you can not bind. This is 
not a problem for a hacker, as the sagr follow basic rule, with proper 
tool, you can generate multiple name until one bind.
A security Guru will then propose to "lock" the user in case of too many 
failure. Not a problem if your goal is to damage the service, but a real 
mess for the real user locked out as well.
>From a user perspective, this solution can be seen as equivalent as 
changing you username on a daily basis, while keeping your password. Would 
you really buy that ?

Last but not least:
- SICF contains many configuration parameter. If you generate SICF for 
each pass, you introduce the chance to use new/wrong parameters which will 
cause random behaviour in the comms.
The parameter change effect (e.g. buffer size) is very insidious and can 
be hard to identify.
>From past experience you will have divergence between pass specific and 
permanent SICF within a year.

You still want to use pass specific ? Good, how will you generates and 
exchange the information for each pass in due time ? How will you 
accomodate late changes/request and update ?
As you don't trust you LAN (that why you want to use pass specific) this 
will be complicated.
During the time DSN/ESTRACK have been using pass specific SICF, this has 
been the killer. The DSN database generating the unique sagr was getting 
rebooted every now and then, the provider and user sagr were commonly out 
of sync. But was not a problem as we have permanent SICF as fall back.

Now to answer to Erik question about what shall be security:
- TM/TC shall be encrypted between control system and spacecraft.
- Update you SLE provider password on a regular basis (but no, don't the 
update the username !)
- To protect your SLE provider, you must build a safe VPN.
- You want to be more safe ? Add a firewall in front of your SLE provider 
to block "agressive" IP coming from inside your VPN.
If a hacker is within your VPN and able to emulate your control system IP, 
you lose. But at that stage you can assume that the pass lost is the least 
of your problem.

To conclude:
Losing a pass shall never lead to a loss of mission.
Passes are lost for many reason on a regular basis (
https://en.wikipedia.org/wiki/Hanlon%27s_razor), and I can not remember in 
the history of space that a mission was lost due to a failed pass.
Due to TC encryption, most of current attacks are of DoS type. Either at 
IP level, which we protect by using VPN and firewall, or for the "very" 
bad guys, by upliningk a pure career to saturate the on-board reciever.
The Chinese got a SinoSat CCTV satellite successfuly hacked by the Falun 
gong group in 2002 using this technic to hijack the payload.
But this can usually be traced back as you need lots of hardware. Be 
prepared to face the wrath of the owner. 
I suggest you have a look to what happens to the Falun gong guys before 
trying you skills on a chinese hardware.

Regards
________________________________________
Martin UNAL
Ground Operation Manager
Ground Facilities Ops HSO - ONO
H-376
ESOC
Robert-Bosch Strasse 5
64 293 Darmstadt
Germany
Tel +49 6151 90 2959 
________________________________________

From:   "Anthony Crowson" <anthony.crowson at telespazio.de>
To:     "Barkley, Erik J (US 3970)" <erik.j.barkley at jpl.nasa.gov>, 
"EXTERNAL-Unal, Martin P (9110-Affiliate)" <Martin.Unal at esa.int>
Cc:     "SMWG" <smwg-bounces at mailman.ccsds.org>, "smwg at mailman.ccsds.org" 
<smwg at mailman.ccsds.org>
Date:   16/02/2021 18:50
Subject:        RE: [cssm] [EXTERNAL] Re:  SACP: configuration of tranfer 
services

At the risk of wading in to a sensitive area, it seems to me that the 
expected advantage of a pass specific SICF over a permanent SICF is 
pass-specific credentials. If the credentials are accidentally exposed, 
there is a much smaller window in which they could be misused.
However, having even one pass hijacked could in the worst case lead to 
loss of a mission.

If I?m already wrong at this state, please correct me gently and ignore 
the rest?

There is an, admittedly imperfect, analogy to the prevalent but outdated 
practice of insisting that passwords are changed every few months. If a 
password is exposed to a malicious actor, it will almost certainly be used 
before a change is forced. Approaches such as two-factor authentication 
are much more useful.

Now the SLE IP, as far as I understand, does not do any encryption ? 
rather, it expects that the network connection would if necessary be 
tunnelled through a secure communications channel. If this is not done, 
then even per-pass credentials will not protect against a 
man-in-the-middle attack. On the other hand, if strong authentication is 
provided by a secure communications channel, completely independently of 
SLE itself, then the SLE credentials become vastly less critical ? more at 
the level of a protection against misconfiguration than against serious 
attacks.

So yes, in the absence of other measures, a pass-specific SICF can provide 
a modest security improvement by limiting credential lifetime. However, it 
is not by itself an adequate protection against modern cybersecurity 
threats. If adequate protection is provided by other means, it is not 
clear that the pass-specific SICF adds significant value. In other words, 
the more productive focus would be on protecting and authenticating the 
underlying connection.

Anthony

From: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov> 
Sent: 16 February 2021 17:02
To: EXTERNAL-Unal, Martin P (9110-Affiliate) <Martin.Unal at esa.int>
Cc: SMWG <smwg-bounces at mailman.ccsds.org>; Anthony Crowson 
<anthony.crowson at telespazio.de>; smwg at mailman.ccsds.org
Subject: RE: [cssm] [EXTERNAL] Re: SACP: configuration of tranfer services

Martin,

You indicate that pass specific SICF is not ?a serious answer? re today?s 
cybersecurity threats. I fail to see how a permanent SICF is a serious 
answer.   Do you have any suggestions? 

Best regards,
-Erik

From: SMWG <smwg-bounces at mailman.ccsds.org> On Behalf Of 
Martin.Unal at esa.int
Sent: Monday, February 15, 2021 7:26
To: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>
Cc: SMWG <smwg-bounces at mailman.ccsds.org>; Anthony Crowson <
anthony.crowson at telespazio.de>; smwg at mailman.ccsds.org
Subject: Re: [cssm] [EXTERNAL] Re: SACP: configuration of tranfer services

Hello

This was discussed in length with Wolfgang Hell at the time we 
discontinued pass specific SICF. 
In term of security, the added value of pass specific SICF is close to 
nil. 

In term of operational failure, the handling of pass specific was causing 
lose of service on a monthly basis. 
And the recovery action was to use permanent SICF. So what the point. 

I have experienced the usage of pass specific SICF, and I can insure you 
this is not something you want to see in human spaceflight operation. 

Cyber security has to be taken seriously. 
Pass specific SICF is not a serious answer to today threat.

Regards
________________________________________
Martin UNAL
Ground Operation Manager
Ground Facilities Ops HSO - ONO
H-376
ESOC
Robert-Bosch Strasse 5
64 293 Darmstadt
Germany
Tel +49 6151 90 2959 
________________________________________ 

From:        "Barkley, Erik J\(US 3970\) via SMWG" <smwg at mailman.ccsds.org
> 
To:        "Holger.Dreihahn at esa.int" <Holger.Dreihahn at esa.int>, "
Marcin.Gnat at dlr.de" <Marcin.Gnat at dlr.de> 
Cc:        "SMWG" <smwg-bounces at mailman.ccsds.org>, "Anthony Crowson" <
anthony.crowson at telespazio.de>, "smwg at mailman.ccsds.org" <
smwg at mailman.ccsds.org> 
Date:        15/02/2021 15:52 
Subject:        Re: [cssm] [EXTERNAL] Re:  SACP: configuration of tranfer 
services 
Sent by:        "SMWG" <smwg-bounces at mailman.ccsds.org> 

Just to add a quick comments to this thread, the DSN also employs 
permanent SICFs for SLE instance configurations. Much like what Colin has 
indicated the implementers complained that it was just too much trouble to 
deal with dynamic SICFs as that would involve more testing and more things 
could go wrong, etc. However given the changing cyber security landscape I 
would ask if, eventually, can you afford not to have dynamically generated 
SICFs or some other equivalent such that access is very much controlled on 
a tracking pass by tracking pass basis ? especially  if you are supporting 
human spaceflight? I think it is something we should keep an eye on.

Best regards,
-Erik

From: SMWG <smwg-bounces at mailman.ccsds.org> On Behalf Of 
Holger.Dreihahn at esa.int
Sent: Wednesday, February 10, 2021 23:45
To: Marcin.Gnat at dlr.de
Cc: SMWG <smwg-bounces at mailman.ccsds.org>; smwg at mailman.ccsds.org; Anthony 
Crowson <anthony.crowson at telespazio.de>
Subject: [EXTERNAL] Re: [cssm] SACP: configuration of tranfer services

Hi Marcin, 
I remember having implemented SLE SICF generation for our scheduling 
system (2008?) and I think we have put some thinking in how to do that. As 
Colin correctly remarks, the feature of pass specific SICFs is not used - 
simply too many files. 

However, the trick at the time was to distribute the information for SLE 
SICF creation to the two relevant places: The mission agreement with the 
(SLE) service requirements and the ground station model with the ground 
station capabilities (amongothers the SLE services supported formulated as 
templates). The two are used for determine 'does the station have the 
required capabilities' and then to combine the information as shown below 
to the configuration (slide 45 of attachment): 

Some background: Our scheduling is service based, so in addition to the 
SLE services we define the underlying production services as operational 
services (TM, TC, DDOR, Ranging, etc.), which are required (mission 
agreement) and matched with station capabilities (station model). Those 
production services are in fact subject to configuration profiles, which 
can be refined by missions per pass or requested service. 
In orinciple the complete configuration profiles could be defined by FRM 
parameters. 

I know it's not exactly what you discuss, but maybe of some interest. 

Best regards, 
Holger 

Holger Dreihahn
European Spacecraft Operations Centre | European Space Agency | H-293
+49 6151 90 2233 | http://www.esa.int/esoc 

From:        Colin.Haddow at esa.int 
To:        "Anthony Crowson" <anthony.crowson at telespazio.de> 
Cc:        "SMWG" <smwg-bounces at mailman.ccsds.org>, "
smwg at mailman.ccsds.org" <smwg at mailman.ccsds.org> 
Date:        10/02/2021 18:46 
Subject:        Re: [cssm] SACP: configuration of tranfer services 
Sent by:        "SMWG" <smwg-bounces at mailman.ccsds.org> 

Hi Marcin, Anthony, 
                                    ESOC has effectivly moved to permanent 
SICfs. The NIS (Neywork Interface System - Handles MCS - Groundstation SLE 
links) was designed to be able to use dynamic as well as permanent SICFs 
and the missions screamed about the prospect of having to use dynamic 
ones, much preferring to use permanent ones. 

Cheers for now, 

Colin 

---------------------------------------------------------------------------------------------------------
Dr. Colin R. Haddow,
HSO-GI, European Space Agency,
European Space Operations Centre,
Robert-Bosch-Str 5,
64293 Darmstadt,
Germany.

Phone; +49 6151 90 2896
Fax;      +49 6151 90 3010
E-Mail;  colin.haddow at esa.int
---------------------------------------------------------------------------------------------------------

From:        "Anthony Crowson" <anthony.crowson at telespazio.de> 
To:        "Marcin.Gnat at dlr.de" <Marcin.Gnat at dlr.de>, "
smwg at mailman.ccsds.org" <smwg at mailman.ccsds.org> 
Date:        10/02/2021 18:23 
Subject:        Re: [cssm] SACP: configuration of tranfer services 
Sent by:        "SMWG" <smwg-bounces at mailman.ccsds.org> 

Hi Marcin, 

As I would see it, and as I think we had it in the old Blue-1 book, the 
service instance identifiers and the parameters you feel are missing are 
part of the service package, not the SA or CP. Your 3 spacecraft 
configurations would be 3 configuration profiles. The SP request may 
identify a specific station or antenna; at any rate, the SP itself will 
identify the aperture and the service instances, and at least port IDs. 
There was a discussion which I don?t think was ever fully resolved, about 
service instance identifiers. The original concept had them being 
dynamically defined for each service package. But the ?stop-gap? SICF 
approach ended up with people getting used to ?permanent? SI IDs and being 
reluctant to change that. Certainly I think it would be unhelpful to have 
to reproduce the same config multiple times just to use different SI IDs 
for different apertures. 
Basically what you suggest in your second and third bullets looks about 
right, modulo discussion on permanence of SI IDs. 

I think the FRM parameters identified as just ?reporting? mean they cannot 
be changed during production. Clearly they have to be set somewhere, i.e. 
?by management?, as part of setting up the service packages. 

Anthony 

From: SMWG <smwg-bounces at mailman.ccsds.org> On Behalf Of 
Marcin.Gnat at dlr.de
Sent: 26 January 2021 15:32
To: smwg at mailman.ccsds.org
Subject: [cssm] SACP: configuration of tranfer services 

- CAUTION: This message was sent from outside of Telespazio Germany. 
Please do not click links or open attachments unless you recognize the 
source of this email and know the content is safe. Please report all 
suspicious emails to "support at telespazio.de" as an attachment. -

Dear SMWG, 

In course of some implementation work and discussion with my developers, I 
came to the point where I think we shall have some closer discussion soon 
(in one of our teleconferences and definitely later during spring 
meetings). 

The protagonist: configuration (profile) of the transfer service (known 
currently under nicknames ?SLE configuration? or ?SICF?). 

The place and time: somewhere in snowy Bavaria during Winter 2020/2021, 
Corona situation. 

The Synopsis: during implementation of VEEEEEERY remotely similar profiles 
into DLR?s new scheduling system, my developers asked me how they shall 
treat the Service Instance Identifiers in the profile. When I looked at 
their initial implementation, I noticed, that they did put the complete 
configuration (service) profile in ?one piece?, according to the current 
list from FRM and to what I told them. It does not correspond to the full 
flexibility of the actual planned SACP (this was not the intention). 
Anyhow, I realized two things: 

1.        Not all of SLE parameters were there (GVCID, Port and User 
identifiers, etc?) 
2.        Defined as such now, projects would need to define multiple 
configuration profiles, being actually the same, differing only with 
Service Instance Identifier, for each Service Instance. In our case, for 
example for TerraSAR mission, we have actual 3 spacecraft configurations 
for the antenna, but in total 32 service instances for different stations, 
antennas and cortexes. This maybe does not multiply 1x1, but at least we 
would need 32 configuration profiles (I can almost hear the project people 
coming to get me)! 

Okay, this is to some extent my own fault, as I burdened the 
implementation of ?some kind of configuration profile? to my developers, 
and maybe did not thought about it in front. But it shows I think also 
some shortcomings we have with the concept (maybe it will shape up still). 

To the first point, I quickly noticed, that ? even I made a list of 
parameters based on FRM ? actually not all parameters are really exposed. 
When looking to the export of Holger out of FRM and the schema files, I 
noticed than there is number of parameters which are marked only as 
?reporting? thus in first place not visible to SACP (hence my omission). 
And so, all Initiator and Responder Id?s as well as PortId?s and the 
GVCID?s are marked as ?reporting? or ?read-only? if you like. How are we 
going to set them? Shouldn?t they be also configurable, similar like 
Service Instance ID? 

>From this: 

To this: 

Second topic is the actual (operational) separation of the antenna 
configuration and the transfer services configuration. Currently (at least 
at DLR) this looks like this: 

There are few antenna configurations (which may be effectively also 
identical throughout different antennas) and number of SLE configurations 
(Service Instances). To be fully honest, the multiplication of the SLE 
config is just due to the different Responder ID and Port ID?s, resulting 
also in separate Service Instance ID, the rest of the config is typically 
the same (for a specific RCF or FCLTU service). 

How do we want to handle that with our current concept of SACP? 

I know we had some brief discussions on that, and there is some three page 
(chapter 3.4.2) information on intended use in the TechNote of John. It 
speaks relatively high level about two options, reusing SICF files (kind 
of an extension to the actual SACP config) and also by dynamically setting 
the abovementioned parameters. 

First option says, that SICF files shall be there, and the Responder and 
Provider ID?s and Ports shall be fixed in Service Agreement and for 
specific Site and Mission, and later on only these shall be used. It does 
not actually however says anything on how actual SICF is bound to the 
specific Service Package nor Service Package Request nor Configuration 
Profile. We have Ports and their ID?s, but how do I know which SICF shall 
I use? Shall there be also predefined ONE fixed SICF? 

Second option of using the extended/abstract parameters in Service Package 
 may allow for dynamic provision of the so called ?scheduledSocket? which 
would be just the ProviderPort. So far so good, but still I miss the rest 
of the SLE/CSTS configuration, especially wrt to what I wrote above. 

Here is where the I lost the trace of the hunted game. And maybe we need 
here some discussion. ? 

I was thinking ? just to came into with some proposal ? of the following 
(better ideas are welcome!): 

-          To not destroy everything else we already somehow managed to 
set up wrt SMURF, SPDF and SACP? 
-          ?We could use extended list (as at the beginning) in the 
Service profile, with Service Instance ID, PortID?s, GVCID?s etc., having 
predefined some parameters (i.e. Buffer sizes), whereas leaving all of 
these ?variable ones? undefined. That way we would have limited number of 
Configuration Profiles (a set of few generic ones for the spacecraft, 
universally engageable in every station). 
-          When booking the Service Package (sending the Request) we could 
?overwrite? the previously mentioned parameters using AbstractParameter 
Class (for example ?InitiatiorID? and ?ServiceInstanceID? and ?GVCID?). 
The same would be true for SPDF ? the values there would be shown in 
AbstractParameter class (and for example additionally station defined 
PortID would be provided). This would allow to use all of our Books / 
Formates as they are, and have individual SLE configuration for each 
pass/service package. 
-          The disadvantage of the above method would be, that there would 
need to be some kind of automated generation of Service Instance ID and 
GVCID on user side and the ProviderPort on provider side. Otherwise we 
come into danger of crazy users/providers not filling these parameters, or 
filling them wrongly or even filling them different. 

Okay? I?m done for today ? 

Cheers 
Marcin_______________________________________________
SMWG mailing list
SMWG at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg 
This message is intended only for the recipient(s) named above. It may 
contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or 
dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies 
appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA 
Data Protection Officer (dpo at esa.int).
_______________________________________________
SMWG mailing list
SMWG at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg 
This message is intended only for the recipient(s) named above. It may 
contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or 
dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies 
appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA 
Data Protection Officer (dpo at esa.int
)._______________________________________________
SMWG mailing list
SMWG at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg
This message is intended only for the recipient(s) named above. It may 
contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or 
dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies 
appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA 
Data Protection Officer (dpo at esa.int).

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210217/4ee15637/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 60793 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210217/4ee15637/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 8215 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210217/4ee15637/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 12585 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210217/4ee15637/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 9567 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210217/4ee15637/attachment-0005.png>